0patching a 0-day: Windows gdi32.dll memory disclosure
0patch.blogspot.com
0patch.blogspot.com
Patching 0-day issues usually is not hard in itself. Usually it is just little errors like missing checks for buffer overflows, or some input not sanitized. What is hard is making sure that everything still works after the patch. And "everything" is quite a lot in the case of this issue (gdi32.dll). You have to make sure that all still supported software depending on gdi32.dll is still working as it should, that includes multiple Windows versions, multiple Office versions, multiple Internet Explorer versions, multiple ... you get the idea. Microsoft has a lot of products.
Not saying that I don't admire this, but I don't know if any company would be willing to install "some patch" by "someone" with no guarantee that it won't break other things or open other holes. I would always want to install an official patch by an official vendor because I have support and warranty.
If we're talking about some legacy software with no support and no vendor taking care of updates - this is something I could get behind and I think is useful.
This was how things worked previously in the industry. There are a number of disadvantages to companies releasing multiple small patches throughout the month:
1. Users may have to reboot their computers multiple times a week.
2. Large corporations (with their own back-compat worries) do their own extensive validation of patches. Multiple small patches puts a large seriously burden on IT departments.
The industry has moved towards larger update bundles for good reason.
Patching a user mode app/dll would not require a reboot, just a restart of the app.
As we try to make 0patch agent robust and reliable we don't support kernel mode at this moment - we will make this step slow and with great caution.
Back in the day when binary patching was the norm, this was a common pain point. Good patches at least did a minimal checksum check to make sure they had the correct starting point. Bad ones made no backups and just went to town, and failures meant reinstalling and trying all over again.
the additional tradeoff you need to consider is that the smaller you make the patches, the larger the number of variations you need to test for later patches, updates, app compat, etc. that is why service packs were a thing - you could baseline after a period of many patches getting out there, and start the process again.
(full disclosure: I used to work on and around some of this at microsoft many moons ago)
There is one important technical difference between small pre-PatchTuesday patches and micropatches: pre-PatchTuesday patches were installed binaries (actually complete new version of the product) that are here to stay forever – or at least until patch uninstall or product upgrade. Imagine how hard is patch uninstall on CEO's patch-corrupted system on a business travel, for instance. Micropatches only live in memory, they die with the process. They don’t change file system and installed product, just redirect maliciously used instruction (just instruction, not the whole function) to correct path, if possible. It’s just couple instructions any admin could review by himself and switch of, if there is a problem. I wish I could say that for today’s patching procedures. For us it is the idea worth trying. We just have to simplify updating process for users (and software vendors, too).
p.s.: we are aware Microsoft gave up the idea of hot patching some years ago, but as I know they were not changing just couple of instructions. Please correct me if I’m wrong.
For the record this was in April 2014, after Heartbleed was disclosed. IE6 had a 4% market share at the time, so yeah.
Even my tech-illiterate father, who has a laptop with XP on it, knows enough to not even connect to the internet with it anymore. He mostly uses it to play solitaire currently, and uses a newer laptop w/ Win10 for anything on the internet.
(edit: grammar)
Surprisingly it is still the only supported vector format in Office...
https://support.office.com/en-us/article/Insert-SVG-images-i...
Only 17 years after the spec was established.
Looks like it's a brand new feature only available since this year and only for Office 365 customers (for now, I hope), given that it's not supported on my Office 2016 build.
What does this say about using Google software versus software from Microsoft? Or am I missing something obvious?
Your statement would also make it unreasonable for Google to be able to find this stuff, but we have existence proof that that's not the case.
His position is absurd. Microsoft could have found it. The thing stopping them is the incredible number of tests you would need to perform to find them all.
The OP asked why Microsoft didn't find this first. The answer is too many things to test. The entire premise of the argument is insane. If microsoft had a viable way to test ALL of the their products for ANY problem, don't you think they would be doing that?
- The original parsers / renderers where written on single user systems and focussed on rendering speed. They didn't anticipate hostile files.
- The original developers are long gone.
- EMF files were never popular on websites.
I would argue that their real mistake was adding EMF / WMF support to IE in the first place. It made sense to developers because it was only a few lines of code, but it was a terrible decision for security.
Forming an opinion about Microsoft vs. Google software quality would require knowing how many similar problems Microsoft found and subsequently patched in their software. Without that data, we can't tell whether Microsoft isn't putting effort into finding vulnerabilities in its software, or whether Google simply got lucky and found something Microsoft missed.
And perhaps scaremongerings us to embrace the cloud, and thus ChromeOS...
As part of MS16-074, some of the bugs were indeed fixed, such as the EMR_STRETCHBLT record, which the original proof-of-concept image relied on. However, we've discovered that not all of the DIB-related problems are gone.