4 ms·

An interesting effort - but the idea of a bug bounty program for 0patching won't work, at least not paid by the companies affected. Patching 0-day issues usual

An interesting effort - but the idea of a bug bounty program for 0patching won't work, at least not paid by the companies affected. 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.

sst8 10y ago
What about getting vendors into changing their patching habbits? Instead of packing some hundred mega patches just provide micro ones when needed? As you said 0day issues are usually (not allways) easy to fix. Probably you alone are skilled enough to check this couple of code instructions by yourself - which is not the case with full-blown patch Tuesday packages. I am pretty sure that process could be much cheaper for MS.
- com2kid 10y ago
  > What about getting vendors into changing their patching habbits? Instead of packing some hundred mega patches just provide micro ones when needed? 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.
  - sst8 10y ago
    Well, with micropatching you don't need to reboot and you only have to review minimum code changes - and if the patch is not working for you you can unpatch it (with proper permissions, ofcourse).
    - j_s 10y ago
      Pretty sure this specific example would require a reboot, changing a Windows kernel DLL. There seems to be some confusion over whether or not the 0patch tool can update the kernel without a reboot, though. https://news.ycombinator.com/item?id=13775550 https://news.ycombinator.com/item?id=13775550 Patching a user mode app/dll would not require a reboot, just a restart of the app.
      - johntb86 10y ago
        I believe this code is in gdi32.dll and is one of the few pieces of GDI implemented in user mode. However you'd probably still need to reboot because almost every program in windows is linked with it and would need to be restarted.
      - dielel 10y ago
        Hi, Stanka from 0patch here. If you want to enable or disable (aka "patch" or "unpatch" the application) you don't need do restart the application. Not even if your app is running and you've just install 0patch agent. This is how it is designed to work in user space. When the official MS patch is installed (hopefully with the fix) this particular 0patch won't apply anymore. 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.
        j_s 10y ago
        Can you please clarify whether or not this specific patch is user mode or kernel mode? @johntb86 mentioned GDI is split and this is the user mode part.
- ryanburk 10y ago
  the microsoft process cost for many individual patches versus larger collections isn't the real issue. behind the scenes, it should be essentially the same. it is a real issue for customers, particularly in IT, to deal with and manage all of those micropatches. especially in a world where you are responsible for validating every patch against your countless internal apps, deployments of updates are not trivial, and you have scenarios like finance where there is SOX compliance, auditing, etc. this is why the model of patch tuesday and the predictability of knowing when the patches were coming (regardless of number) and ability to plan your testing & deployment was loved by IT departments. 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)
  - dielel 10y ago
    ryanburk, thanks a lot for your comment. We at 0patch are big fans of MS Patch Tuesday from it's very beginning. It was a huge improvement for appsec for more than decade and it still is. But as active pentesters with more than 15 years of experiences we just noticed that our enterprise customers can not apply patches timely and usually their (also critical) systems remain unpatched for several months. It looks they cannot cope with the amount of update changes and testing so they rather decide not patch. That was even worse than not to have a patch from official vendor. 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.
j_s 10y ago
I assume eventually end users will pay for the fixes they choose to use, and the choice will be based on the level of risk the patch mitigates and the reputation of the entity creating the patch.
- Declanomous 10y ago
  I would just choose a different software provider at that point. Though I suppose that could be fairly effective at getting enterprise users who are stubbornly holding on to a particular version of software to move on. Like my IT director for example, who sent a long rambling email to everyone about how horrible it was for all of us that Microsoft was leaving us out to dry by not supporting IE6. For the record this was in April 2014, after Heartbleed was disclosed. IE6 had a 4% market share at the time, so yeah.
  - hermitdev 10y ago
    Wow, if I worked for a company that was still on, at latest, Windows XP and Windows Server 2003 in 2014, I think I'd be looking for a different job. 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)
    - Declanomous 10y ago
      I am looking for a different job, and it's largely in part due to issues with the IT situation. I basically have stuck around this long because while the IT situation is Kafkaesque, I've really liked a lot of other aspects of the job, and it was in a field I feel strongly about.

sst8 10y ago

What about getting vendors into changing their patching habbits? Instead of packing some hundred mega patches just provide micro ones when needed? As you said 0day issues are usually (not allways) easy to fix. Probably you alone are skilled enough to check this couple of code instructions by yourself - which is not the case with full-blown patch Tuesday packages. I am pretty sure that process could be much cheaper for MS.

com2kid 10y ago
> What about getting vendors into changing their patching habbits? Instead of packing some hundred mega patches just provide micro ones when needed? 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.
- sst8 10y ago
  Well, with micropatching you don't need to reboot and you only have to review minimum code changes - and if the patch is not working for you you can unpatch it (with proper permissions, ofcourse).
  - j_s 10y ago
    Pretty sure this specific example would require a reboot, changing a Windows kernel DLL. There seems to be some confusion over whether or not the 0patch tool can update the kernel without a reboot, though. https://news.ycombinator.com/item?id=13775550 https://news.ycombinator.com/item?id=13775550 Patching a user mode app/dll would not require a reboot, just a restart of the app.
    - johntb86 10y ago
      I believe this code is in gdi32.dll and is one of the few pieces of GDI implemented in user mode. However you'd probably still need to reboot because almost every program in windows is linked with it and would need to be restarted.
    - dielel 10y ago
      Hi, Stanka from 0patch here. If you want to enable or disable (aka "patch" or "unpatch" the application) you don't need do restart the application. Not even if your app is running and you've just install 0patch agent. This is how it is designed to work in user space. When the official MS patch is installed (hopefully with the fix) this particular 0patch won't apply anymore. 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.
      - j_s 10y ago
        Can you please clarify whether or not this specific patch is user mode or kernel mode? @johntb86 mentioned GDI is split and this is the user mode part.
ryanburk 10y ago
the microsoft process cost for many individual patches versus larger collections isn't the real issue. behind the scenes, it should be essentially the same. it is a real issue for customers, particularly in IT, to deal with and manage all of those micropatches. especially in a world where you are responsible for validating every patch against your countless internal apps, deployments of updates are not trivial, and you have scenarios like finance where there is SOX compliance, auditing, etc. this is why the model of patch tuesday and the predictability of knowing when the patches were coming (regardless of number) and ability to plan your testing & deployment was loved by IT departments. 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)
- dielel 10y ago
  ryanburk, thanks a lot for your comment. We at 0patch are big fans of MS Patch Tuesday from it's very beginning. It was a huge improvement for appsec for more than decade and it still is. But as active pentesters with more than 15 years of experiences we just noticed that our enterprise customers can not apply patches timely and usually their (also critical) systems remain unpatched for several months. It looks they cannot cope with the amount of update changes and testing so they rather decide not patch. That was even worse than not to have a patch from official vendor. 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.

j_s 10y ago

I assume eventually end users will pay for the fixes they choose to use, and the choice will be based on the level of risk the patch mitigates and the reputation of the entity creating the patch.

Declanomous 10y ago
I would just choose a different software provider at that point. Though I suppose that could be fairly effective at getting enterprise users who are stubbornly holding on to a particular version of software to move on. Like my IT director for example, who sent a long rambling email to everyone about how horrible it was for all of us that Microsoft was leaving us out to dry by not supporting IE6. For the record this was in April 2014, after Heartbleed was disclosed. IE6 had a 4% market share at the time, so yeah.
- hermitdev 10y ago
  Wow, if I worked for a company that was still on, at latest, Windows XP and Windows Server 2003 in 2014, I think I'd be looking for a different job. 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)
  - Declanomous 10y ago
    I am looking for a different job, and it's largely in part due to issues with the IT situation. I basically have stuck around this long because while the IT situation is Kafkaesque, I've really liked a lot of other aspects of the job, and it was in a field I feel strongly about.