Starting on the other side of this airtight hatchway: Running a program that leaks memory
A security vulnerability report came in that said
In the most recent Windows Insider Build, the
pingprogram has a small memory leak. This is normally not a problem because thepingprogram runs for less than a minute before exiting, but if you runping -t, then it will ping the destination machine indefinitely until killed. This can be used as a denial of service if you just start aping -tand let it run. It leaks about a megabyte a day.
While it’s true that you could use it as a denial of service, it’s also not a very effective one, given that the memory leak is “only” a megabyte a day.
Furthermore, in order for an attacker to exploit this, they need to gain the ability to run programs so they can run ping -t and giggle with glee as the program slowly leaks memory.¹
Since this presupposes that the attacker can run a program with arbitrary command lines, the attacker may as well use something that consumes memory at a far faster pace:
for /L %i in (1,1,1000000) do start eventvwr.exe
This launches a million copies of Event Viewer, which will certainly mess up the system faster than a one-megabyte-a-day leak.
What we have is a bug but not a security bug. The development team fixed the memory leak, so this bug didn’t exist for very long.
¹ In practice, the program will have to leak several gigabytes of memory before the system will start to suffer, so the attacker is in for a wait of several years before their denial-of-service attack finally bears fruit and the system owner will have to either kill the rogue ping process or reboot the system. “With this fiendish attack, I can mildly inconvenience somebody a dozen years from now!” (Assuming they leave the system running without rebooting.)
Light
Dark
5 comments
I’ve found a lot of “vulnerabilities” which presuppose the attacker already has access to the system. I suppose it’s a matter of definitions versus practicality.
Side note: my RSS reader (I know…) stopped pulling things from this site. When I checked on the feed, it doesn’t validate anymore…
https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fdevblogs.microsoft.com%2Foldnewthing%2Ftag%2Fhistory%2Ffeed
I think it’s because there’s a newline being added as line 1 before the xml tag starts.
I guess they can also mildly inconvenience somebody half a dozen years from now if they run two instances.
Before Windows becomes actually unstable it sends a message to the Desktop that it is about to “end some programs due to exhausted system resources”. I haven’t seen that message, ususally combined with Event 2004, for a few years now. But I did see it when I tried to encode 16k h264 video with only 64 GB RAM, or 12k videos with only 32 GB RAM. The result is that the offending task is force-ended. So in that ping situation the ping would be force-ended after a few years.
Maybe. Maybe not. How does Windows know which program is leaking memory, so it can kill the right one? It does not. Consider this scenario: There is a program leaking memory, and some other random program asks for more memory, and Windows does not have more to give to that random innocent program. So it kills the innocent victim, since it is the one who made the impossible to fulfill request. The innocent program might be explorer.exe, you know, the shell, task bar, desktop icons and all that. Maybe there is other out of memory strategy, like killing the biggest working set program, or creating more swap until you run out of disk space and slowing your computer to crawl during that, or straight bug check (blue screen), or something completely different. But in general, the OS could not know whether the leaking program is really leaking memory or whether it actually needs it to do its stuff.
Windows would never actually become unstable.
For a real-world example of this you can look at the Vista Sidebar. One of the gadgets had a memory leak. Slowly you would fill up your virtual address space with stuff you never read again. Equally slowly, Windows swaps out these unused pages to disk. Eventually Sidebar.exe had allocated all 2 GB of its virtual address space, and would crash because there was no place left to allocate memory in its 2GB virtual address space.
It’s not like your user-mode program is consuming *RAM* on the PC. Programs don’t allocate RAM; they allocate memory.
And at 1 MB/day, i’m *certain* your PC will have rebooted before the 5 years it takes to exhaust your 2 GB virtual address space.
Think of it this way:
– in Windows 95,
– with 4 MB of RAM
– my 32-bit program can allocate, and use, 2 GB of memory
– it is allocating 2,000 MB on a machine that “only” has 4 MB of RAM
That is not a problem.
Allocating 500 million time more “memory” than there is RAM, doesn’t mean i’ve exhausted the RAM of the PC.