4

How unique is this bug?

Is there a more sophisticated and well-studied attempt behind? Is it accidence? The article below says "continouos stream to UDP". What stream? Just an hour stream of zeros? 1.000.000 PSs of 1601 bytes packets of zeros?

Of the information provided around this bug, it look "accidentally discovered". The issue are described as related to ports without services (could it really be a risk?). Also, the bug appears as a TCP/IP bug, but affects only Windows 8 / Server 2008 / Windows Vista FW.

Is it really a TCP/IP bug?

Or a FW bug that covers with the looks-more-complicated-approach "It's a TCP/IP bug"? To make technicians more satisfied because TCP/IP is less Microsoft-bundled?

An article about the bug fix (rather then MS own info).

|improve this question
  • 2
    Microsoft are generally very good about providing info in their advisories (see @Ninefingers answer) - I would generally recommend a combination of Microsoft bulletins and industry postings, such as h-online – Rory Alsop♦ Nov 10 '11 at 10:17
6

Microsoft's own info is quite descriptive for this issue. It's a reference counter overflow vulnerability. In very simple terms, imagine you have a piece of code like this:

size_t num_of_connections = 0;

That's how you'd keep track of the number of connections, but you also have to contend with the fact size_t has a limited size. If you keep adding 1 to size_t eventually you will "overflow" the integer value. What happens at that point depends on the sign of the data.

Say for a minute that all registers are 4-bit. This is not true for your PC, but keeps the numbers workable! So the maximum unsigned value we can hold in a single register would be 1111 = 15. Suppose we do 15+1. The answer is 10000 = 16 but that can't fit inside our 4 bit register. There are two things that could happen. If you use a standard x86 add instruction, that extra 1 just falls off into the abyss, never to be seen again. So the result according to your program would be 15+1 = 0. If you're using adc, the result is the same, but the carry flag would be set and the next adc would also add 1 to the result. For interest's sake, C does not use adc or use the carry flag.

Now, the other alternative is that we're using a signed value. In this case the maximum positive value is 0111 = 7 and the maximum negative value is 1111 = 8 (using two's complement). If you add one to seven, you still overflow , so 0111+1 = 1000 which implies 7+1 =-8.

The problem is not that this happens - it's that you make an assumption in your code based on the set of values that may appear and then do not handle the case of an overflow (and of course that an overflow will not cause any exception or error at all - it just happens). Subtraction can also be a problem, where you go from small values to a large value because you've "overflown" the other way. You might find the phrack article on the topic to be quite an interesting read.

So, to answer your question, whilst I don't know specifics, I suspect that the bug is a result of any old packets being sent let me clarify that before an explosion erupts in comments underneath... the bug will probably be caused by any old packets being sent, but likely just cause a crash. To actually exploit it you need a way to get the payload in - i.e. control what happens with the crash. That's where choosing your packets carefully comes in (thanks Hendrik, +1); enough of them to overflow whatever ref counter is being used here. Is this a unique vulnerability? Not really - it's a known issue. It's not a bug in TCP, since UDP and TCP are different things. It's a bug in the handling of UDP packets in Microsoft's TCP/UDP stack. Handling ports on which services are not listening is still a potential area of security risk - since the OS must correctly reject these packets and handle any potential floods of such packets.

To mitigate such issues in your own code, the advice from the CERT-C guidelines on integers is useful, particularly INT03-C.

|improve this answer
  • 2
    "TCP/IP" is the confusing short-name of the Internet protocol family which includes TCP and UDP among lots and lots of other protocols. – Hendrik Brummermann Nov 10 '11 at 17:28
  • Yep and even more confusingly, when people say there's a bug in TCP/IP it sounds like a bug in the protocol... which is not the case! – user2213 Nov 10 '11 at 17:45
  • 1
    Microsoft says it could enable remote code execution. That makes this sound more serious than just causing a crash. – D.W. Nov 11 '11 at 5:22
  • Well, I was really brushing over the detail on that front, since I don't know it. As I say - it's not the integer overflow that's necessarily the problem, it's what the code does as a result. Since I don't know what the refcounter actually does, I decided for once I'd just stick to a plain old explanation of integer overflows and link a relevant discussion. It's still a bug; I'm guessing it was discovered due to a crash and that people realised on debugging it there was potential for an exploit. But without reading that analysis, I can't say exactly how severe it is. – user2213 Nov 11 '11 at 9:19
  • Even more amusing in my mind (although I left it out of my answer) is that mp_limb_t in GMP is added using adc. mpz_t is just an array of mp_limb_t which are just typedef'd integers matching the register size. So in fact, arbitrary precision arithmetic in one prominent bignum library relies on integer overflows to function, at least in the assembly optimised versions where such things are supported (i.e. add with carry). – user2213 Nov 11 '11 at 9:27
6

The vulnerability could allow remote code execution if an attacker sends a continuous flow of specially crafted UDP packets to a closed port on a target system. https://technet.microsoft.com/en-us/security/bulletin/ms11-083

So while a huge amount of UDP packets with all bits set to zero may result in a crash, it is unlikely that it will result in code execution. They need to contain content specifically written to exploit the issue.

It is an reference counter overflow according to the same Microsoft source.

What is a reference counter?

When a program allocates a block of memory, a reference counter may be used to manage it. Whenever a part of the program code wants to access it, the counter is incremented. Whenever this part of code is done working with the memory block, the counter is decremented. When the counter reaches 0, nobody is interested in the memory block any more, and it is freed.

What is an integer overflow?

Integers are numbers used for counting. They have a fixed size in computer memory. For example 32 bit or 64 bit. So unlike integers, you know from mathematics, there is a largest possible number. Adding 1 to that number will either result in a very negative number or 0.

In other words, if you add 1 again and again, you will end up with 0.

What is a reference counter vulnerability?

A reference counter vulnerability is usually caused by a program path that fails to decrement the reference counter. The attacker is therefore able to increment the counter again and again.

As a result, he can get the counter to 0 and beyond (see previous section). After he got the counter to overflow and ended up at 1 again, he will trigger the normal program path that will decrement the counter.

Now the counter reached 0. 0 means, nobody is interested in the memory block anymore, so it will be freed.

What is the error path in this context?

The program path that fails to decrement the counter is used when there is no service listening on the UDP port.

It is easy to conclude that an open UDP port is required for the final decrement to exploit the issue. Microsoft, however, did not mention this. Furthermore they stated that the Windows Firewall offers no protection against this bug. Therefore the conclusion is likely wrong.

Why is freeing used memory blocks a bad thing?

Freeing memory just means that it is marked as "available". Someone else, who requests a block of memory, may therefore get it. But the original program still thinks, it owns the block and can use it as it wants.

So we end up with two programs using the same memory block without being aware of each other. This obviously leads to data inconsistencies.

With a bit of bad luck and special crafting, one of this programs may do bad things to the other. Imagine that the other program is storing program code, pointers to program code, or trusted data that will result in pointers to program code in this memory block.

Is this a real risk?

Yes. It is not easy to exploit and sending a such a huge amount of UDP packets over a slow Internet connection will likely be noted. But it is real issue that needs to be patched.

|improve this answer
  • 1
    The discussion about memory freeing bugs is not quite accurate. For one thing, memory free bugs are more serious than you mention: they frequently can enable malicious code injection attacks, which are very high severity. For another thing, the harm does not come by one program messing with another program's memory; that is impossible, because the OS will zero memory blocks previously used by one process before allocating them to another process. – D.W. Nov 11 '11 at 5:21
  • Yes, it is a simplified version, which I hope non-programmers can understand. I considered adding the corruptions of the memory management caused by a second free and related aspects, but I thought it was getting too confusing and just went with "trusted data structures". //// I am not using "program" as a synonym for "process" but as "a sequence of instructions to implement an algorithm", so a TCP/IP stack contains many programs and memory management is just another program. Is that definition uncommon in English? It may be a false friend since even in German "program" has several meanings. – Hendrik Brummermann Nov 11 '11 at 5:47
  • This bug is likely not easy to exploit for two reasons: The details of free memory bugs are more difficult than an SQL injection attack or a simple (unprotected) stack overflow. As far as we can guess from the report, it requires receiving billions of UDP packets and that is likely to be noticed. But it needs to be patched quickly anyway: Exploiting this bug is worth a lot of money and therefore "not easy" is no obstacle. – Hendrik Brummermann Nov 11 '11 at 5:59
  • Ah-hah! Yes, I was interpreting "program" as "application", and a process as holding a running instance of a program. I don't know if it is a language difference or just a false assumption on my part (Minor: I might use "part of the code" or something instead of "program".) The more important part is the consequence: it can allow remote code execution, i.e., it can allow the attacker to inject malicious code into the Windows kernel and take control of your machine. I like your non-technical explanation of integer overflows, etc. Your point about the difficulty of exploitation is well-taken. – D.W. Nov 11 '11 at 6:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.