
SIGRed: A 17 Year-Old Bug in Windows DNS Servers - bonfire
https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/
======
hyperman1
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.

~~~
etothepii
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.

~~~
hyperman1
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.

~~~
cesarb
> > The bug has existed since 2003

> 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).

------
core-questions
[https://msrc-
blog.microsoft.com/2020/07/14/july-2020-securit...](https://msrc-
blog.microsoft.com/2020/07/14/july-2020-security-update-
cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/)

> 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.

------
mips_avatar
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...](https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-
more-secure-code/)

~~~
bonfire
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-...](https://research.checkpoint.com/2020/bugs-on-the-windshield-
fuzzing-the-windows-kernel/)

------
LinuxBender
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:_

    
    
      net stop dns && net start dns
    

[0] - [https://support.microsoft.com/en-us/help/4569509/windows-
dns...](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-
remote-code-execution-vulnerability)

