The article also felt like Rust does it this way because all these other projects which came before it did it this way. Someone originated the technique and no one questions its validity, without seeing if there was an alternative method to achieve the same result.
I did spend about 20 minutes looking into this, it seems that there's an (admittedly undocumented) IOCTL which is in the Winsock headers (MSWsock.h) called SIO_EXT_POLL which seems to just use the poll device IO control code and so they could probably do this without messing with low-level AFD weirdness.
That said you'd think with Microsoft going all in on Rust, last I heard at least, that they could find a way to re-implement this code correctly. Hell, if they at least documented the IOCTL they could probably get co-pilot to do it for them ;)
That dialog is only on Google websites, I'm not sure how that is abusing its power as you can choose not to use Google products (hard but doable). Regardless Microsoft are already doing that to push Edge as well, try going to microsoft.com using a non-Edge browser and you'll see a banner appear. But this goes much further and actively bakes those prompts into the OS and browser, you wonder how far they'll take it?
If you enabled the posix subsystem NTFS became case sensitive as well, although most API passed a flag to disable that for Win32 file calls.
It’s interesting that Microsoft effectively added the reverse feature to NTFS [1] to support per-directory case sensitive files to be more compatible with Linux.
It’s an proof of concept exploit for a vulnerability in the sandbox used by FF which is a security boundary to reduce the impact of RCE. The reason for the injection is I don’t just have a working RCE lying around (we get them fixed) and using one would add additional complications and obfuscate the bug when reporting. The purpose of a proof of concept is to demonstrate impact so that it can be fixed.
In Chromium we do have integration tests for the sandbox functionality as a whole and unit testing but it doesn't cover things like this as we're testing Chromium's ability to sandbox not whether the OS's primitives have broken. We might notice if all of a sudden our sandbox stopped working, but for something which only exhibits a problem when it's being actively circumvented we won't.
I can't speak to what MS do testing wise, considering the age of some of this code it seems likely there's no test for this specific functionality otherwise you'd assume it would have been noticed. Testing for security defects is inherently difficult anyway, especially logical flaws where you don't get a nice crash. This case is different but in general you usually need some specific setup process to get the system into a vulnerable state which is hard to achieve without knowing ahead of time the bug you were trying to detect.
Basically my PoC works exactly the same from Chrome GPU as FF Content Level 5 [1] there was no additional hardening. It was also easier to test as FF doesn't enable the Microsoft DLL signing mitigation should I could just do a direct CreateRemoteThread -> LoadLibrary without messing with KnownDlls.
Ah I see what you mean :-) We'll yes I left out the RCE as I'm not an RCE person, I look for sandbox escapes and privilege escalation bugs. The injection of a DLL is to test rather than as an exploit.
I was originally going to write about using the same bug in Firefox. The default content sandbox in FF is basically the same as Chrome GPU, so any untrusted HTML/JS coming from the web could exploit RCE to get into a sandboxed process where this bug could be used. I decided considering they're using the Chromium sandbox code it really should be about Chrome.
That said, this sandbox escape isn't being presented for practical reasons. It'd be incredibly noisy to do and potentially unreliable due to the various mitigations you have to circumvent. Any "real" attacker would likely use an exploit in the kernel's WIN32K component which is accessible from GPU.
You can bet I'm salty. I do Windows research and I am a owner of the Chromium Windows sandbox code so I have a vested interest in this.
The problem with dealing with Windows and by extension Microsoft is there's no way of inspecting what they've changed from version to version other than by RE or having test cases. However, we try and avoid writing unit tests for behaviors Microsoft's responsible for, but of course in many cases MS don't have those tests either so these things fall through the cracks.
I'm not sure why I'm replying to the proverbial as you seem to have made up your mind, but being the original author of the blog post I thought I'd at least try and correct some seeming misconceptions.
First off, the reason it's called "Windows Exploitation Tricks" is it's a blog post series ([1], [2], [3], [4]) of behaviors/tricks of the Windows OS that allow you to exploit security vulnerabilities, specifically logical privilege escalation vulnerabilities. If you read the introduction to [1] it outlines the purpose of the series, it's based on ways of exploiting real world vulnerabilities that I've discovered in real software whether it be in core Windows or third-parties. The rationale for writing them up is if you look for exploitation techniques and tricks on any platform almost everything you'll find it based around memory corruption, I don't look for fuzzed bugs so having a cool ROP chain is going to be much help to me and no doubt others who find themselves in this situation. So I write up interesting techniques I've discovered over my years of research to the benefit of others.
There are secondary benefits to blogging about these techniques, for example it can act as developer education. If you look at the API referenced in the blog [5], you'll not see any security warning or advice associated with it. This leads developers to misuse the functionality without understanding how the OS works. The irony is not lost on AV vendors having no clue about the security principles of the OS they're protecting from security threats. Still if you've never seen a program using the PID (through whatever means it's got that value) being used for authentication on Windows or any other OS then I can only assume you've never really looked very hard for logical vulnerabilities.
Another benefit is an aid to reporting. What I blog about in the series are not security issues in a traditional sense, instead they're chain building 'gadgets'. You might have a root vulnerability but not the means of exploiting it. In an ideal world a vendor would remove all non-essential functionality which could facilitate exploitation but we live in the real world and MS are not generally going to spend their time fixing something like this as a real security issue with a CVE etc. Therefore there's no real reporting process for me to follow to report it and demonstrate impact to MS, and as is typical if I find instances of the bug class which can be exploited with the trick they'll fix the reported bug, not the technique. However by making it very public it gets noticed by MS, for example [1] and [2] are both now fix/mitigated in the Windows 10 1903 in direct response to the blog posts.
Finally I think you don't fully understood the scope of the example vulnerability I gave. The root cause of the Check Point bug is the service 100% trusted that the PID being passed from the named pipe was a useful piece of information to base a local security decision on (see end of the "Interacting with the Service" section). It used that PID as the start of a chain of checks to determine if the process at the other side of the pipe was a Check Point trusted application. The fact that in this case the whole logic of the check was fundamentally flawed is irrelevant for the purposes of the blog post. If their certificate checks had been completely robust and it wasn't possible to either spoof them or just inject a DLL then spoofing the PID would absolutely have allowed you to exploit that vulnerability.
The private symbols have in the past ended up on the public symbol server (and quickly taken down), they have ending up "shipping" in public symbol packs. I can't point to specific incidents as the links to them no longer exist. This is why I said accidentally as they were not released as a conscious effort on MS's part.
However you seem to want to claim the only place those symbols can come from is being stolen. Of course in this case you use leak as a synonym for stolen, bit leak can just as much mean they were released accidentally by the owner, MS can't steal their own private symbols and release them on the web. I'm sure there's some symbol files traded in private scenarios which are actually taken through non public means but there have been actual incidences of public release of private symbols.
I'm not trying to claim that ReactOS is clean, I have no skin in the game from a project or user perspective. For all I know it might have lifted significant portions of its code from stolen source code or the WRK (which isn't stolen in so much as used without permission, which I'd regard as a totally different thing). I do however take exception to the typical software engineer's view there are somethings which cannot be reverse engineered into a almost similar form.
As to why ReactOS is stuck in the early 2000s, it could be because of all the source code which was stolen and put wholesale into the project. Although if that was the case I'd have expect MS would have sued the living shit of the project by now. It could also be because Windows was and is a very complex OS with many layers which if you're trying to re-implement with a team of 10s to 100s versus 1000s it's going to take a lot of time. It's seems unlikely that the project would spend the millions of man hours to create the abomination that is UWP.
Perhaps the best way to determine if ReactOS is unclean is for MS to open source the Windows Kernel, hell why would you even need ReactOS then :-)
Well that's categorically untrue. Sure they don't release private symbols intentionally but they have done in the past accidentally. At that point it becomes a bit of a grey area, undoubtedly leaked/stolen source code is a no-no but reversing from private symbols when they do leak seem harder to quantify as you still need to reverse engineer the code, just structures/names etc are already known.
Private symbols are not the only way of gleaning more information, other examples I can think of are:
* Checked builds (prior to Win10). These builds shipped de-optimized kernels (e.g. no inlines) typically with copious debug strings which gave away important details. For example I gleaned a lot of knowledge of ALPC MSRPC from the checked build of rpcrt4.dll from Windows 8.
* SDK/DDK headers, especially in the brave new world of insider previews with preview SDK/DDKs there is sometimes information present which should not have been released including "private" information. Again bit of a grey area.
* The private symbols MS do ship. For example a significant proportion of the COM runtime has private symbols, intentionally. You can extract from those a surprising amount of system call structure information.
I'd recommend watching Alex Ionescu's talk at OffensiveCon about how he does reverse engineering on Windows to see many of these things in action. https://www.youtube.com/watch?v=2D9ExVc0G10
I'm not saying any of this would make it a clean-room re-implementation but to say ReactOS cannot possibly have been reverse engineered without just up and copying source isn't true.
No, blame the movie studios, record labels etc. They're the one which require asinine DRM support for web browsers. Google/Microsoft/Apple/Adobe want to support media content, but to do so requires towing the line with the media companies otherwise they refuse to license the content (at least in HD+).
Having worked with various DRM teams I know that they have to treat their code as if its the most secret code in the world, if they don't the media companies can swoop in and ban them and then no Netflix for your users. This is why Widevine code isn't open source (other than the glue EME code) and is almost certainly the reason for the refusal to work with a small open-source form of Chromium. If for example the project was used to "steal" content the media companies would be mad at Widevine, with lasting repercussions for all Chrome users.
It's worth noting that typically all DRM teams work as if the hosting environment is an adversary. For example Widevine don't trust anything Chrome says as someone could recompile it and lie about the security. The only times this is relaxed is where the platform is deemed secure, such as CrOS or iOS.
Yes it’s just as vulnerable (example [1]), but I think .net serialization is exposed less often to untrusted inputs than Java with its myriad of enterprise software.
It's worth noting that ALT+X gives you the default OEM code page for compatibility with DOS sigh whereas ALT+0X gives you Unicode. So typing ALT+0163 will give you £.
I'd take a guess that the save tricks might be more anti piracy. After all the gba had flash carts, perhaps these carts contained sram and eeprom so checking for it was to block it. No idea about the pipeline stuff though, perhaps checking vram was working correctly?
Well at least with hard links that's not strictly true. Using official win32 apis you need write permission on the file you're linking to so you can't link to say a system file as a non admin. Try mklink with the /H switch.
Of course that's a bit of a lie, if you use the NtSetInformationFile api you don't need write access :-)
That's exactly it. The contact had flash source but they get the DRM code shipped as a binary library so never see the source of it. A lot of companies, MS, Google, Adobe compartmentalise their drm team, effectively at the behest of the media companies as its all smoke and mirrors anyway. trying to protect things like encryption keys and the like. Typically therefore the binaries are also obfuscated heavily.
I think you're also missing the point that adding mitigations into a platform is about reducing the number of exploitable bugs and ideally making the ones which are still exploitable take more time, are less reliable and cost more. I think this fits the car safety analogy pretty well.
If you want to think of this in the car safety analogy then consider all possible ways of killing someone in a car before and after the changes in safety standards. In the bad old days random events could kill you but if you had a targeted attacker they could use the same techniques and just drive a car into you, or force you into a wall. Now with newer safety standards the chance that a random event would kill you is much reduced, but the targeted attacker (assuming they don't just fire a bunker buster at you) needs to spend time researching the type of car, finding weak points, developing something to exploit those weak points etc.
So it goes with exploit mitigations. It wasn't that long ago that running a fuzzer on a product (and sadly fuzzers are still useful) would yield a massive amount of trivially exploitable bugs. These days, not as much, at least in mature platforms. You could think of the fuzzer discovered "random" bugs to be the case exploit mitigations are trying to protect against (re random collisions which car safety protect against). Even the simplest stuff like stack cookies make exploitation significantly harder. Are there no stack overflow bugs? Nope they still exist. Are they completely unexploitable? Nope, especially in the hands of a skilled attacker. Are you protected against randomly introduced bugs which cause a stack overflow and have a low chance of having some useful behaviour which makes them exploitable? Absolutely.
Honestly if someone _wants_ to _kill_ you I'm sure they could. If the attacker is willing to spend the time, effort and money to find better, more exploitable bugs and you're a target worthy of their efforts then you're screwed no matter what exploit mitigations you put in place (this is why imo bug hunting still has some semblance of value). But are you _that_ important? Would the FBI be willing to a throw a $1m iOS exploit at you for example?
Not sure you can do it easily with SMB/CIFS (maybe some NAT tricks) but depending on the level of FS support you want it's pretty easy to do it with WebDav. You can mount a webdav share pointing to localhost on an arbitrary port (I believe it's of the work \\localhost@portno\DAVWWWRoot). From there I'm sure you could proxy out to any other FS implementation you liked. It also probably isn't great for large files etc due to the way WebDAV works of course :-)
I did spend about 20 minutes looking into this, it seems that there's an (admittedly undocumented) IOCTL which is in the Winsock headers (MSWsock.h) called SIO_EXT_POLL which seems to just use the poll device IO control code and so they could probably do this without messing with low-level AFD weirdness.
That said you'd think with Microsoft going all in on Rust, last I heard at least, that they could find a way to re-implement this code correctly. Hell, if they at least documented the IOCTL they could probably get co-pilot to do it for them ;)