Slashdot Mirror
Windows Update Can Hurt Security
An anonymous reader writes "Researchers at Carnegie Mellon University have shown that given a buggy program with an unknown vulnerability, and a patch, it is possible automatically to create an exploit for unpatched systems. They demonstrate this by showing automatic patch-based exploit generation for several Windows vulnerabilities and patches can be achieved within a few minutes of when a patch is first released. From the article: 'One important security implication is that current patch distribution schemes which stagger patch distribution over long time periods, such as Windows Update... can detract from overall security, and should be redesigned.' The full paper is available as PDF, and will appear at the IEEE Security and Privacy Symposium in May."
Windows _____________ Can Hurt Security
Microsoft has cautioned its enterprise customers by responding with a white paper that finds security and profits to be independent variables. The widely criticized paper uses Microsoft's own software history as a model business thriving in this manner.
...
Seriously, a reason that the consumer needs Microsoft more to bail them out? I couldn't think of better news for Microsoft's future
You are damned either way. The only way to avoid complete damnation from security vulnerabilities is to run a large number of different operating systems, but then you are damned to live a life in complete confusion about system maintenance instead.
The onion principle is a general security term that has been defined a long time ago, but the fact that we are all online in some way or another all the time means that the onion is rotten.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Just roll the entire i386 directory into every patch.
There is no good solution to this problem -- that fixing something makes it easier to find old problems. At some point, users need to be responsible enough to apply updates.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
Profitability is key, not security. Think of sysadmins as janitors. We pay you to wipe up the mess. It's not worth our while to invest in systems that don't create a mess as long as janitors are cheap enough to come with their electronic mops and buckets.
And you are.
Sorry.
... patch based security is also the model linux uses (as far as I understand).
Furthermore, for Linux access to the unpatched code is also easy to obtain.
Somebody please correct me if I'm mistaken.
Tie two birds together: although they have four wings, they cannot fly. (The blind man)
The vendor CANNOT depend upon the users/admins patching their systems all the time.
The vendor MUST ship with the minimum number of services running BY DEFAULT and with the minimum rights for those services.
My problem with Microsoft on that is that they did NOT minimize the number of services. They put a software firewall in front of them.
Meanwhile, I can put a vanilla Ubunut workstation on the 'Web without a firewall.
Of course there are going to be flaws in this kind of release/patch system. The problem it trying to become savvy enough that you don't need "automatic" updates and can actually patch what needs patched on your system as it needs updated.
I've heard reports of bugs created by patches and patches to fix bugs from patches that only took it back to base version.
Ask not what you can do for your country. Ask what your country did to you
M$ need to stop having a fixed update day and go back to having them come out when they are ready and not waiting for the next patch day.
5) "???"
If it's possible to generate an exploit that quickly, we need to completely abandon the current "patch it and hope no one broke in" approach to security. It's never been a good approach, but if any idiot can generate exploits via a point-and-click program, that's obviously a big problem. This problem isn't limited to Windows, and most operating systems aren't patched within even a few hours of a patch release. There's good reasons for this, and bad ones. But no one really wants to trust their critical systems to be patched (and possibly go down and become unworkable) to an instant patch system.
The fundamental problem here is that a lot of security depends on single points of failure. A real security system relies on the "defense in depth" approach.
AccountKiller
There are millions of Macs out there. If cracking them was that easy, they'd be cracked. There's just too much money there even if the Windows market is almost 20x larger.
This research seems to miss one critical point: you have to have administrative privileges to apply the vulnerability-generating patch. That's not a success crack, since if you already have administrative privilees you own the machine. It's no different than with linux: you have root, you win. Michael Howard et. al. have been over this countless times through blogs, books, and whitepapers. Just because you can identify or even generate a vulnerability doesn't mean you can exploit it.
Now, granted, when users run as admins this does pose a problem which is one reason - and obviously not the only, based on comments made by Microsofties that have appeared as stories here on /. - that UAC exists. Not the prompts, but more to the point that administrators do even run with a full privileged token: just a normal user token with the privilege to escalate with a simple yes/no dialog.
On top of all this, IIRC it was IT administrators that wanted a consistent release schedule to avoid a fire drill of internal testing every time a patch came out.
Wow. Who knew?
This author takes full ownership and responsibility for the unpopular opinions outlined above.
Couldn't this process (modified of course) do the same thing to any update for any software at all?
How exactly is this news? I mean, I should update my software when there's a new patch anyway, but now that THIS has been developed I...need to update my software when there's a new patch... Automating it is a pretty neat trick, and it pretty much destroys any argument for security through obscurity, since it means you couldn't patch any hole to maintain the obscurity, but it's not like security through obscurity in the computer software realm has that amazing a track record in any case.
The PDF outlines three methods of alleviating the problem of staggered patch distribution:
1) Patch Obfuscation: basically an attempt to hide exactly what the patch fixes by padding out the patch with a lot of lines of nonsense. While this might prove effective, it would only be effective until an improved algorithm for discerning the true reason for the patch is found, and in the meantime, it would create its own set of problems, particularly if the level of obfuscation required balloons the size of the patch to an unmanageable degree.
2) Patch Encryption: basically distributing the patch in an encrypted format, waiting until it is reasonable to assume that everyone has the patch, and then transmitting a decryption key to decrypt and apply the patch more or less "simultaneously". Problems: this only pushes the problem back one level; meaning the same method of exploitation is just as possible, while this also creates an unacceptable time lag for patches to be applied, which hackers who write exploits the old-fashioned way can exploit to their considerable benefit.
3) Fast Patch Distribution: basically leveraging technologies like P2P to insure that patches are rolled out...well...fast. Problems again include off-line hoists, as well as hosts who have the misfortune of being on ISPs that take a dim view of P2P.
In summary, none of the methods outlined have much of a chance to combat this new threat.
____
~ |rip/\/\aster /\/\onkey
Here where I work, Windows Updates brings some of our older servers to a crawl, and sometimes even knocks out our network for our remote branches. Thankfully, I'm not one of the Windows guys here. :) Our AS/400 (iSeries) runs so much more smoothly.
Posting anonymously obviously to protect the innocent.
Unfortunately, no fix is feasible. The basic problem is twofold:
- If you tell someone how to fix a problem, you tell them what the problem was.
- It's not possible to push updates to all affected systems simultaneously.
That the first is true should be obvious if you think about it for a minute. As for the second, that comes from the fact that the affected systems are owned by different entities with different requirements and different environments. A fix for a problem affects more than just the fixed software, especially when the fix is in the operating system on which other business-critical software runs. Any fix has to be checked for compatibility with that entity's specific environment, this checking can't start until after the entity has gotten the fix, and everybody's going to take a different amount of time to check and get clearance to deploy.The only "fix" would be a mandatory push to all systems at one time, and that won't be accepted by the people who own the systems unless Microsoft or someone else accepts complete 100% liability for all costs associated with any failure. And I just don't see that happening.
What would the new system look like? The best I have so far is something that distributes the patch, encrypted, and then releases the key some time later when many systems already have the patch downloaded and can install it immediately. Of course, I'm not sure how much that improves over just using bittorrent to distribute the whole thing with much higher aggregate bandwidth.
Not to be inflammatory, but it really is.
Essentially, these people wrote a paper which says that hackers can analyze Windows Updates and figure out how to attack systems that aren't patched yet thereby. It goes into theory and proofs of that. Thanks, everyone else knew this about Windows Update years ago, probably for about as long as there's been a Windows Update.
It then proposes some solutions which are all, on the whole, worse than the status quo for various reasons. For example, forcing all Windows machines, whether they're turned on or connected to the internet or not, to patch at the very same instant is not realistic.
They should've called this thing: "Windows Update has problems. Magic can fix them."
Comment removed based on user account deletion
...test every patch in a VM or a machine with a similar hardware set. Period! Turn off Automatic Updates and tell it to not bother you or the user because it's turned off.
The game.
And if what you say now is correct, then there's no reason why the research team could not have included Mac updates and Ubuntu updates.
I do not see them picking Windows because it is Windows.
You can't have everyone everywhere past patched at the exact same time, and even if it were possible, it is not a good idea.
Let's suppose that someone did come up with a good way to distribute patches to the whole world instantaneously & simultaneously.
Now let's suppose that Employee X at Microsoft accidentally put the wrong version of the latest patch into the system, and that this version of the patch fixes the targeted problem, but breaks the MS TCP/IP stack in the process.
What would happen if every single Windows box in the entire world simultaneously lost all network connectivity?
Scenario 2: Employee Y at Microsoft deliberately puts a maliciously edited patch into this instant distribution system, and now has a rootkit on every windows box in the whole world?
Somehow I think it is a good thing that some victims... I mean people get patches before other people do.
There, fixed that for you. (Sorry, couldn't resist)
Black Tuesday is rather important to many organizations as it gives them a target for workload planning on patch integration, testing and roll-out. Overtime can be good. ;) The fixed day is not the issue. IMHO, poor coding discipline is. http://www.sans.org/gssp/SANS-SSI%20C%20Blueprint%20(9-07).pdf
Invenio via vel creo
The result of a bad patch: Global instant borkensystem. With option 3 it's similar -- Fast Global Hosenboxen. Nobody would consider option 1. It too obviously won't work.
Nope... it's time for the Bazaar.
Help stamp out iliturcy.
This is fascinating. As someone who's worked with automatic theorem proving and proof of correctness techniques, I'd never thought of using them in this way.
What they're doing works like a proof of correctness system in reverse. They difference executables before and after the patch (which in itself is impressive), then, having isolated the patch, analyze it automatically. Security patches usually consist of adding a test which constrains the valid inputs at some point. So they use a symbolic decision procedure, which is part of a theorem prover, to work back through the code and automatically derive a set of inputs that would be caught by the new test.
This is more than just an attack on Windows Update. It's true automated exploit generation.
This is potentially applicable to any security-critical code that changes over time. One could, for example, have something that watched check-ins to the Linux kernel tree and developed new exploits to current stable releases from them.
If you have a patch, you can diff the original and the patched file and find out what got fixed. No secret here.
So how can you close the gap between fixing and exploiting? That's nothing MS could fix. You have to. Patch early, patch often.
If any message is contained here, it's that if there is a patch out and you didn't use it, you're extremely vulnerable. That's pretty much it, nothing really new here.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
...just do it right the first time. Alright, so maybe that's not quite feasible, but that is because you can't possibly fix something like this completely. If you have bugs in your code, they can be found one way or another. Simple as that.
1) Isn't this an old problem? Not only is this old, but it applies to any computer system, so to single out Windows Update seems naive (as others have said).
2) I think we are forgetting that the exploits still need to be distributed, and the article refers to worms, but how is this different from any other worm/virus?
Smarter viruses will attack weaknesses that are yet widely known or patched, so those that use exploits based on public patches are 1) stupider and 2) more predictable.
So this is less of an "update how" problem, and rather more of an antivirus problem. The previous might be impossible to solve, but the latter we have solutions for.
And what happens when someone who has downloaded the encrypted patch has his system compromised because you're waiting for some idiot who hasn't to do so before you'll release the key that unlocks it? In a worst case scenario, you could end up facing a class action suit for not enabling the patch. I don't know if such a suit could be successful, but I'd bet someone would try it. At present, if someone has failed to update his system with the latest patch, it's not Microsoft's fault. Under this system, if Microsoft was refusing to actually make the patch available to one until others have it, that poses ethical and legal questions. I'm not a lawyer, and can't say what the legal answer would be, but I'm sure the question would arise.
Microsoft thought about this. In the latest update, they've decided that to improve security, they'll disable all input devices on your computer.
By making a users computer useless, the goal is to get fewer people using computers, thereby reducing security problems.
No sig for you!!
don't release patches, because then people will be able to reverse-engineer the patch. Great idea.
Or distribute encrypted patches over the course of a day, then when you publish the key everyone can update
Which shifts the problem from distributing the update to distributing the key.
Of course this does have another advantage: Distributing the encrypted update also distributes notification that there WILL be a key, and can tell the users when. Then it becomes a race to get the key and apply the patch before the bad guys can get the key, generate, and deploy an exploit.
And the downside: The bad guys also know the patch is coming, and when. So they can use their existing botnet(s) to grab a key as soon as possible, then DDOS the key distribution mechanism while they generate and deploy the exploit. This makes things WORSE: A much larger fraction of the machines are vulnerable when the exploit deploys.
Still worse: If the bad guys crack the encryption, or manage to break in and grab the key early, they get to automatically generate and deploy an exploit while NOBODY has the fix. Oops!
Ditto even if they don't crack the patch - but the patches exposes that a vulnerability exists and perhaps what module has it, and they find and exploit the vulnerability before the key deploys.
= = = =
In a battle between weapons and armor, weapons eventually win.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Distribute an encrypted patch, and then once all clients have downloaded it reveal the key, which is short and can be sent in a single network packet.
Which shifts the problem from distributing the update to distributing the key.
Of course this does have another advantage: Distributing the encrypted update also distributes notification that there WILL be a key, and can tell the users when. Then it becomes a race to get the key and apply the patch before the bad guys can get the key, generate, and deploy an exploit.
And the downside: The bad guys also know the patch is coming, and when. So they can use their existing botnet(s) to grab a key as soon as possible, then (or simultaneously) DDOS the key distribution mechanism while they generate and deploy the exploit. This makes things WORSE: A much larger fraction of the machines are vulnerable when the exploit deploys.
Still worse: If the bad guys crack the encryption, or manage to break in and grab the key early, they get to automatically generate and deploy an exploit while NOBODY has the fix. Oops!
Ditto even if they don't crack the patch - but the patche exposes that a vulnerability exists and perhaps what module has it, and they find and exploit the vulnerability before the key deploys.
= = = =
In a battle between weapons and armor, weapons eventually win.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
As the article suggests in its last paragraph. Windows Update needs to rethink itself. Perhaps a patch CD. I have many problems installing updates. LARGE UPDATE DOWNLOADS TINY PATCH APPLICATION ON SHUTDOWN Use my XP SP2 system as an example. It has about 84 updates that download every single day slogging up my first fifteen minutes of work while my PC downloads every patch. Then only one dinky patch MIGHT get applied when I shut down. DOWNLOADS ALREADY APPLIED PATCHES. Another example is unintelligent update download. I manually downloaded and applied the time zone patch (KB946723). But MS keeps downloading and trying to apply this patch. EXPRESS INSTALL (NOW) FAILS MISERABLY. I just now tried to install 88 updates with nothing else going on on my PC. Every single update failed. Is this a way to run updates? This reflects rather poorly on Microsoft. Jim
Think of sysadmins as janitors. We pay you to wipe up the mess. It's not worth our while to invest in systems that don't create a mess as long as janitors are cheap enough to come with their electronic mops and buckets.
That works for small messes.
It doesn't work for somebody getting hold of the company's trade secrets, client list, bidding information, road map, and headhuntable employee names and pay scale.
It doesn't work for somebody cracking the information on the company accounts and transferring the cash reserves to themselves via untraceable paths.
It doesn't work for somebody destroying or corrupting the IT infrastructure - especially the databases - and taking the company out of business for days or forever, causing key employees to quit or be fired, etc.
It doesn't work for somebody corrupting industrial process control infrastructure and literally destroy plants and kill employees, or cause the company to build and ship defective products.
I could go on.
Cleaning up IT graffiti is one thing. Cleaning up IT nuclear strikes is quite another.
IMHO any corporate IT exec who treats malware like graffiti, rather than an early warning of something more serious, is negligent in his fiduciary duty to the shareholders and perhaps criminally negligent in his duty to protect the lives and health of the employees. (Pity that most of 'em do treat the threat in this way. B-( )
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Unless Microsoft starts using something like satellite technology and distributes a satellite receiver to every user of Windows, you'll always have to deal with lag for getting patches out.
It's called "IP Multicast".
Does YOUR ISP support it?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
2) Patch Encryption: basically distributing the patch in an encrypted format, waiting until it is reasonable to assume that everyone has the patch, and then transmitting a decryption key to decrypt and apply the patch more or less "simultaneously".
This can make things worse:
The distribution of the patch alerts the bad guys to the existence of the bug.
- They can use their botnet infrastructure to get the key early and DDoS the key servers (possibly simultaneously, using the botnet to grab the key through the DDoS leaks). This may end up with a larger unpatched population when they deploy their exploit.
- If they can crack the encryption or break into the distribution mechanism and grab the key early, they can deploy the exploit while NOBODY is patched.
- If the existence of the patch alerts them to the existence and possibly to the location of a vulnerability, they may find it by other means before the key is released, again deploying an exploit while the whole population is unpatched.
3) Fast Patch Distribution: basically leveraging technologies like P2P to insure that patches are rolled out...well...fast.
This just changes the timescale and is subject to DoSing as well. It also (as others have pointed out) opens the opportunity to poison the torrent/whatever with fake or corrupted versions of the patch - installing their own back door if possible, delaying or halting the updating to widen their exploit window in any case.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
What's important about this is that it can quickly and automatically generate exploits given only OBJECT code - faster even than a good programmer could do it from source.
This negates the claim that hiding the source code increases security.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
But based on my reading of the paper, it isn't 100% there. You don't get "sploit.exe" dumped onto your disk when the thing is all done. Their stuff only works backwards to a certain point.
For instance, when they come up with the exploit for WMF reader vulnerability, they're not making you a new WMF file (as I understand, anyway).
One thing that interested me is the model they invented. The binary differencing was off-the-shelf stuff from eEye. But their model of the x86 machine (cpu, instruction side effects, registers, and memory) is new, and that seems like something that could have been written previously.. I'm surprised they needed to do this. They also define a space of functions that examine the model to determine if badness has happened, for each specific kindof badness they're interested in, i.e. return address changes during execution of call.
They also appear to require execution traces of P (or P') to run under a machine monitor; I don't think from the instructions in P they work backwards from P/P' difference lines and construct initial conditions of the machine state. Even if that _is_ what they were doing, they only model the salient portions of the binary, not the outside system.
Even so, what they're doing here is fantastic. The things they're not doing (automatically creating files that trigger the exploit) are all possible offshoots from this paper, if one were to have sufficient computing power and time to create models of the salient portions of the system. For each different data flow into the instruction/memory space, the model would need to describe the line of demarcation. In the case of the WMF/PNG vulnerabilities, that line is on the other side of readfile or mmap or whatever. (i.e. the bytes that trigger the exploit come from the disk). Building a file on disk in a certain way to cause a sequence of x86 instructions to produce the desired memory is a hard problem in and of itself, although I perhaps possible with the tools and techniques they've already got.
The same would be true of the ASP.NET vulnerability. I beleive they can work backwards from exploit to the in-memory representation of a URL request. At that point, knowing that URLs come from the outside hostile internet, through IIS, etc etc etc, is vuln-specific domain expertise. However, a library of injection points (file on dist, URL request from network, packet from network, etc) could be built around the analysis model. The analysis engine works backwards until it says "here is the memory precondition that leads to an exploit, now i rely on an injection plugin to acheive that memory state."
My opinions are my own, and do not necessarily represent those of my employer.
Not eating can make you hungry.
Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
It should be a fundamental _tenet_ of publishing academic papers that you get them proofread or copyedited by someone not in the Computer Science department.
First, KB946723 isn't the time zone patch. It's a Vista patch for hibernation blue screen errors.
Next, your problem is that the Windows Update client is broken on your system. To fix it:
1. Stop the BITS and Automatic Updates services.
2. Delete C:\Windows\SoftwareDistribution\. It will be recreated later.
3. Start BITS and Automatic Updates and go back to Windows Update.
If that doesn't work, then IMX following this KB article will fix it eventually:
http://support.microsoft.com/kb/822798
If you're not sure what Windows Updates is doing, check the log file located at C:\Windows\WindowsUpdate.log (NOT 'Windows Update.log'). You can always search that for the error numbers the updates are throwing.
Just because it's Windows doesn't mean you don't have to know how it works.
The road to tyranny has always been paved with claims of necessity.
Avast (AV scanner), Apple software like iTunes, QT and Safari, as well as Acrobat, Sun Java, Real, Winamp, Limewire, my Comodo firewall, Weatherbug, Paint.net and about 20 other packages all seem to have managed to figure out the 'call home' feature so they know whether there's an update or not for me to decide to pull down. And then low and behold I grab one big binary that executes and installs itself.
.NET.
Funny how MS hasn't figured that out yet. As it is the last 13 patches I installed totalled only 2x the size of the ginormous Adobe updates I get regularly. And those MS patches included some huge chunk of
So here would be my recommendation for MS. Give me a widget that looks at the current build, constructs a detailed version datefile, compares that to the latest and greatest at Casa De Redmond, then gives me an arbitrary bundle with ALL of the patches even if I already have a few of them. Then when I execute that single binary it tells me the same thing that DLL installers already do which is "The version you are installing is at the same or prior level as the one you have installed" and automatically skips it by default. It performs the same sideways installation for locked files in the process tree at that time, and cues me for a reboot to finish installing the locked objects.
You know, like everyone else does.
And CRC was never designed to be in the least secure against that sort of thing in the first place. It's a good error checker, but it's not secure.
Yes, there are newer hashes that don't currently have any known vulnerability. But none of which you can be confident that they'll still have no vulnerability in half a decade's time. And if Microsoft were to build what you're suggesting into Windows, a vulnerability beign discovered in whatever hash they used would be a death-knell. How could Microsoft possibly fix it? Distribute a patch to change the hash -- over the compromised patch distribution network?
What's purple and commutes? An Abelian grape.
Except that MD5 has been cracked. That is to say, there are known methods of creating a file with a high probability of having the same MD5 as some original file.
Yes, there are newer hashes that don't currently have any known vulnerability. But none of which you can be confident that they'll still have no vulnerability in half a decade's time.
And if Microsoft do what you've suggested and build such a system into Windows, what would happen if a vulnerability is discovered in the hash they used? How could Microsoft possibly fix it? Distribute a patch to change the hash used -- over the compromised patch distribution network...?
What's purple and commutes? An Abelian grape.
On connecting to the internet, each machine compares its patch level with a master (probably a distributed database). It does this in a state that's analogous to 'windows safe mode' - it isn't running anything non-essential, and has no services available.
If the patch level is such that connection is unsafe, a patch is downloaded and applied before any additional functionality is allowed.
This fails for some organisations where there is considerable local cracking activity and imperfect access to the internet (so a machine might come up and be unable to contact the database, leaving it still vulnerable to local attacks). Any other flaws ?
Rather, it is an issue of putting in effort X and choosing to bypass return Y (millions of machines) in order to fight every other cracker out there for a chance at return 20Y.
Now, you can say that every single cracker in the world does that
or
You can say that cracking a Mac is more difficult than cracking a Windows box. In which case Mac security is better than Windows security.
A zombie army of a million Macs is just as efficient (and valuable) as a zombie army of a million Windows boxes.
Or you could run a browser in a VM, and as for your computer, seal it off with a firewall, enable PAX, use NX, scan your files, and general good security practices?
As a security researcher myself, I sometimes wonder when difficult research that leads to exploits is the right thing to do. Of course, I think that most of the time it is, or I wouldn't be in the business, but this sort of story is still troubling sometimes.
I hereby place the above post in the public domain.
SHA-1, SHA-2, HMAC, ... Technology doesn't stand still, for every problem a solution.
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
this news is pure FUD because all OS's are affected, NOT just only Windows.