It surprises me how basic this exploit is. You choose an important target(Windows domain controller), you select a slightly obscure corner (DNS on a DC), you find boundary conditions to violate(int16 overflow). You keep pushing until something gives.
What you need to fibd this is effort and solid engineering, not genius. Which means the bug itself is fairly trivial and hence avoidable low hanging fruit. A code review or security should find this
This is pretty damning for microsoft and the software industry in general.
The bug has existed since 2003, software development practices and tools, such as code review and pull requests have come a long way since then. I find it hard to remember what it was like doing development work at my first job in "the bank" back in 2011. 2003 must have been another world.
In the general world i'd agree with you. But microsoft was at that point still at the forefront of software dev. They had build servers etc... They knew about best practices from IBM, including code reviews.
What changed was the internet. Before that, say until 1998, they could deliver shoddy code without much impact, and the underpowered machines required cutting a few corners. But it saddled them with a legacy of horrible code.
But they know better now. I'd expect them to audit code as critical as this somewhere between 2003 and now.
Also, integer overflows are something the processor could protect against. See e.g. the 'into' x86 insn. It got dropped because disinterest used in x64. If microsoft wanted, it could have added a compiler flag that injected into after every add. Compile system critical services with it. Intel would make sure into was optimized in their next processor. This would have reclassified almost all overflow bugs from code execution to dos, overnight. We took bigger performance hits for other security code in the past. Oh well, history took an other path.
> But microsoft was at that point still at the forefront of software dev.
The moment Microsoft decided to get serious about software security (after being a laughingstock for years) was with the release of Windows XP SP2, which according to Wikipedia, was released in the middle of 2004. If the bug is from 2003, it's probably older than Microsoft's push for security.
> Also, integer overflows are something the processor could protect against. See e.g. the 'into' x86 insn.
I'm not sure that instruction would have helped here. From what I understand, this was not a traditional integer overflow (which could have set the overflow flag), but instead an integer truncation (using only the lower 16 bits of the register).
> Today we released an update for CVE-2020-1350, a Critical Remote Code Execution (RCE) vulnerability in Windows DNS Server that is classified as a ‘wormable’ vulnerability and has a CVSS base score of 10.0. This issue results from a flaw in Microsoft’s DNS server role implementation and affects all Windows Server versions. Non-Microsoft DNS Servers are not affected.
70% of bugs patched on Windows are memory bugs (buffer overflow, use after free, etc.), linked source below. If someone could make a fuzzer that actually finds these, the nature of our constant security update world would change.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
I think the attack vectors in Windows are so so large that fuzzing to find everything is close to impossible (or even physically impossible). However there are bugs found by fuzzing that were disclosed in Windows - for example https://research.checkpoint.com/2020/bugs-on-the-windshield-...
Here is the registry work around for those that can not patch right now. [0]
To work around this vulnerability, make the following registry change to restrict the size of the largest inbound TCP-based DNS response packet that's allowed:
Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
Value: TcpReceivePacketSize
Type: DWORD
Value data: 0xFF00
The default (also maximum) Value data = 0xFFFF.The recommended Value data = 0xFF00 (255 bytes less than the maximum).You must restart the DNS Service for the registry change to take effect. To do this, run the following command at an elevated command prompt:
What you need to fibd this is effort and solid engineering, not genius. Which means the bug itself is fairly trivial and hence avoidable low hanging fruit. A code review or security should find this
This is pretty damning for microsoft and the software industry in general.