New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 1644
Owner:
Closed: Nov 17
Cc:

Blocking:
issue 1644



Sign in to add a comment
link

Issue 1647: Windows: DfMarshal Arbitrary File Delete Elevation of Privilege

Reported by forshaw@google.com, Aug 24 Project Member

Issue description

Windows: DfMarshal Arbitrary File Delete Elevation of Privilege
Platform: Windows 10 1803 (not tested earlier, although code looks similar on Win8+)
Class: Elevation of Privilege

Note, this is a report on a single issue class in the DfMarshal unmarshaler. For background see the master issue.

Summary: The storage objects can be configured to auto-delete when the object is deleted. This can be hijacked through shared memory to delete any file with the privileges of the process the object was unmarshaled into.

Description:

The storage implementation can automatically delete the storage file when all references to that object are closed. The full path to the file is stored inside the global file stream pointer (in shared memory, naturally) and so can be modified by an attacker. One place where file deletion occurs is in the CFileStream destructor as shown:

void CFileStream::~CFileStream() {
  CGlobalFileStream pgfst = this->_pgfst;
  hPreDuped;
  if (hPreDuped != INVALID_HANDLE_VALUE)
    CloseHandle(hPreDuped);
  if (hFile != INVALID_HANDLE_VALUE) {
    TurnOffMapping();
    CloseHandle(hFile);
  }

  if (pgfst->_dwTerminate == 2) { <-- If dwTerminate is 2 then go straight to delete.
    this->GetName(&ppwcsName);
    this->DeleteTheFile(ppwcsName);
  }
  
  ...
}

Once the destructor is called (which will happen during unmarshal in most cases) then if the global file stream has the dwTerminate value set to 2 the code will delete the file. This delete will run with the privileges of the code which unmarshaled the object, if in a system service this would allowing deleting the majority of files on the system. This isn’t the only instance of course.

Fixing wise, as you have a file handle to the file in question you could call delete on that file directly. Alternatively you could presumably open the file originally with delete on close so that it’s automatically deleted for you without having to explicitly do so.

Proof of Concept:


I’ve provided a PoC as a C# project, I’ve provided one solution for all issues, but separate projects for each bug. This PoC uses the Audio Server to create a shared section and sends the marshaled object to the BITS service. This abuses the CFileStream::~CFileStream issue I highlighted above. It’s the simplest one to demonstrate the general class of issue.

Note I’ve only tested this on Windows 10 1803. While I expect the underlying bugs exist on other versions offsets/behaviors I’m relying on might differ. Also note that once the BITS service crashes the DCOM activator might not realize for a while and so starting COM object will take a long time. You can get around this by manually starting the BITS service if it doesn’t auto-start. A final note, as this uses the Audio Server it might not work on VMs with the sound card disabled.

1) Compile the C# project. It will need to grab NtApiDotNet from NuGet to work.
2) Run the PoC DeleteFile as a normal user passing the path to a file to delete (it should be one that the user can’t delete but system can).
3) You can attach a debugger, but this issue shouldn’t crash so just hit ENTER.
4) Hit enter in the PoC.

Expected Result:
The marshal fails, or the code falls back to using standard marshaled object.

Observed Result:
The BITS service deletes an arbitrary file.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available (whichever is earlier), the bug report will become visible to the public.
 

Comment 1 by forshaw@google.com, Aug 29

Project Member
Labels: MSRC-47437

Comment 2 by forshaw@google.com, Nov 17

Project Member
Mergedinto: 1644
Status: Duplicate (was: New)
Marking as a duplicate of the master issue as only one fix was issue for all the bugs.

Comment 3 by forshaw@google.com, Nov 20

Project Member
Labels: -Restrict-View-Commit

Sign in to add a comment