Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Windows Update Can Hurt Security

kdawson posted more than 6 years ago | from the manufacturing-exploits-on-internet-time dept.

Security 220

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

Sorry! There are no comments related to the filter you selected.

Quiz (5, Funny)

Lord Grey (463613) | more than 6 years ago | (#23118964)

Fill in the blank:

Windows _____________ Can Hurt Security
  1. 1) "Applications"
  2. 2) "Network Connectivity"
  3. 3) "Update"
  4. 4) "Users"
  5. 5) ""

Re:Quiz (0, Redundant)

xjlm (1073928) | more than 6 years ago | (#23119028)

6) "All of the above" I don't usually pay any attention whatsoever to these Windows Security updates except for comedic value. I use Debian behind two firewalls so it really doesn't affect me.

Re:Quiz (1)

onefriedrice (1171917) | more than 6 years ago | (#23119346)

It does effect you if you use the same internet as the rest of us. Compromised Windows machines slow down the internet.

Re:Quiz (1)

xjlm (1073928) | more than 6 years ago | (#23119738)

That may well be, but the only time i notice any real congestion is around the time all the local kids get out of school and turn their computers on. I get download rates as high as 900k and upload at over 100k (unless I'm running KTorrent).

Re:Quiz (5, Funny)

4D6963 (933028) | more than 6 years ago | (#23119052)

Fill in the blank:

Windows _____________ Can Hurt Security

  1. 1) "Applications"
  2. 2) "Network Connectivity"
  3. 3) "Update"
  4. 4) "Users"
  5. 5) ""

  1. 6) "Profit"?

Re:Quiz (0, Redundant)

MacDork (560499) | more than 6 years ago | (#23119142)

6) "Profit"?

(7) Cowboy Neal.

Re:Quiz (0)

Anonymous Coward | more than 6 years ago | (#23119222)

(7) Cowboy Neal.
(8) Not enough options.

you got it wrong (1)

yanyan (302849) | more than 6 years ago | (#23119218)

5) "???"

Re:Quiz (0, Insightful)

Anonymous Coward | more than 6 years ago | (#23119160)

Fill in the blank:

Windows _____________ Can Hurt Security
1) "Applications"
2) "Network Connectivity"
3) "Update"
4) "Users"
5) ""


"Alternatives"

Show me a non-Windows OS, and I'll show you a huge security hole in your network security.

Three are risks in everything we do... or don't do. No big surprise. But honestly... trying to say that updating your OS is bad security? That's a huge stretch, even for Slashdot.

Re:Quiz (1)

dogmatixpsych (786818) | more than 6 years ago | (#23119228)

Show me a non-Windows OS, and I'll show you a huge security hole in your network security. Three are risks in everything we do... or don't do. No big surprise. But honestly... trying to say that updating your OS is bad security? That's a huge stretch, even for Slashdot.


But that begs the question that all updates are completely secure. Just because something is an update doesn't mean it is better.

Re:Quiz (1)

lorenzo.boccaccia (1263310) | more than 6 years ago | (#23119438)

ms-dos

Re:Quiz (1)

German_Dupree (1099089) | more than 6 years ago | (#23119172)

No, you don't even need a blank.

Re:Quiz (0)

Anonymous Coward | more than 6 years ago | (#23119260)

I think that's what the null string was for.

Re:Quiz (1)

somersault (912633) | more than 6 years ago | (#23119552)

It wasn't null, it was just empty >_>

I think FTA is wrong: "a fundamental tenant of security is to conservatively estimate the capabilities of attackers". That means that you should always underestimate the capabilities of attackers. WTF? :P Someone needs to look up the definition of 'conservative'!

Re:Quiz (1)

somersault (912633) | more than 6 years ago | (#23119574)

# oops
$comment =~ s/FTA/TFA/ ;

Re:Quiz (0)

Anonymous Coward | more than 6 years ago | (#23119818)

No. You are all wrong. It is not a question at all. It just says:

"Windows Can Hurt Security."

Re:Quiz (1)

theeddie55 (982783) | more than 6 years ago | (#23120078)

There is no blank Windows Can Hurt Security

Microsoft's Response (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23118988)

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

Doesn't matter (4, Insightful)

Z00L00K (682162) | more than 6 years ago | (#23119050)

You can never distribute patches synchronously to all the PC:s in the world. And you can't hide what the patch fixes.

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.

Re:Doesn't matter (4, Insightful)

Loether (769074) | more than 6 years ago | (#23119120)

I admit I didn't rtfa. however if you use bittorrent or a similar system everyone downloading at the same moment would work better and faster. Everyone would have the patches very close to the same time. At the very least that would decrease the amount of time a potential attacker has to attempt this.

Re:Doesn't matter (2, Insightful)

Nos. (179609) | more than 6 years ago | (#23119186)

Its not that simple. My parent's turn their computer on maybe twice a week. Other's don't have constant net connections.

Re:Doesn't matter (1)

Sancho (17056) | more than 6 years ago | (#23119256)

But as pointed out, this is not a flaw specific to Microsoft. The only way that it's reasonable to target a specific vendor in this case is if they don't dump the patches on everyone simultaneously. Users applying patches in a timely fashion isn't the issue.

Well, either that, or you're advocating not issuing patches at all. That sounds like a pretty bad idea.

Re:Doesn't matter (1)

Nos. (179609) | more than 6 years ago | (#23119612)

I never suggested it was vendor specific. There is not a good way (that I see) of getting around this, except as Z00L00K originally mentioned, the onion principal. Security comes in layers, if you're using layers of security, an exploitable hole in a specific application may not actually make you vulnerable, or be high risk. That's why my desktop machines are firewalled and NAT'd. That's why I run more than one virus scanner. That's why I follow simple guidelines with email and web surfing.

Re:Doesn't matter (0)

Anonymous Coward | more than 6 years ago | (#23119750)

At 0 for 3, I think it's time you took the refresher course in correct apostrophe usage [angryflower.com] .

Re:Doesn't matter (1)

Nos. (179609) | more than 6 years ago | (#23119870)

If you're going to try an be a grammar nazis, you'd think you would at least get it right. I got 1/3 correct. There was nothing wrong with my usage of "don't"

Re:Doesn't matter (3, Insightful)

legirons (809082) | more than 6 years ago | (#23119902)

Or distribute encrypted patches over the course of a day, then when you publish the key everyone can update

Re:Doesn't matter (1)

Opportunist (166417) | more than 6 years ago | (#23119942)

Huh? Distributing a fix through a network of computers not under your control to increase security?

Sounds insane at the first glance, could make more sense with a bit of tweaking. There is a very large number of machines wanting the fix. Now, one may safely assume that the majority of machines get a "good" fix, and only a few machines try to seed a backdoor. If you find a way to connect to your peers and ask them for some footprint of their patch (MD5, CRC, whatever), you can validate whether the fix you get is good or bad.

Yes, that could work. I have no idea what legal thinks about such a system of "peer pressure", though. You'd hand over a lot of power to your users.

Re:Doesn't matter (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23119146)

You can never distribute patches synchronously to all the PC:s in the world.
True enough.

And you can't hide what the patch fixes.
Wrong. You can encrypt the patch.

Steam has no problem distributing games to players so that they can all unlock them on release day. All you have to do is preload the patch with staggered downloads but not send out the key until the same time. Then all machines can decrypt and patch and install them at roughly the same time, helping to greatly cut down on the time between when the patch can be figured out and the time that machines are still vulnerable.

Not fool-proof, of course, but it seems like something Microsoft should seriously consider doing.

Re:Doesn't matter (2, Insightful)

Jarjarthejedi (996957) | more than 6 years ago | (#23119358)

Which does nothing to help out those who either can't (insert system admin worries here) or don't patch their machines.

The current system works fine for those people who autopatch. It takes only a very short time to get the latest patch, shorter than it takes to get the bug, find a good page to work it onto, build up enough trust to get people there, and then deploy it. All this really affects is those users who don't patch their machines.

Re:Doesn't matter (1)

Sancho (17056) | more than 6 years ago | (#23119174)

At one time, patches were delivered to corporate customers in a different time frame than standard windows update users, weren't they? Also, beta patches would suffer from flaws, as those are also staggered.

Nonetheless, outside of these two cases, it seems like Microsoft is being targeting because, well, they're Microsoft. They have a huge market share and a really good update management system, so they're a big target for something like this. That coupled with their history of vulnerabilities, and it's easy to understand why they were picked over, say, Apple.

Nope. That's a logic error. (1)

khasim (1285) | more than 6 years ago | (#23119274)

Nonetheless, outside of these two cases, it seems like Microsoft is being targeting because, well, they're Microsoft. They have a huge market share and a really good update management system, so they're a big target for something like this. That coupled with their history of vulnerabilities, and it's easy to understand why they were picked over, say, Apple.
Nope. If that were correct, then Apple would see 5% (or so) of the "virus" development out there.

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.

Re:Nope. That's a logic error. (1)

Sancho (17056) | more than 6 years ago | (#23119506)

Did you misunderstand me?

It's easy to understand why the researchers picked Microsoft's Windows Update over Apple's Software Update. We're not talking about exploits, we're talking about the paper.

Well you were not very clear. (1)

khasim (1285) | more than 6 years ago | (#23119608)

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.

Re:Nope. That's a logic error. (0)

Anonymous Coward | more than 6 years ago | (#23120080)

Nope. If that were correct, then Apple would see 5% (or so) of the "virus" development out there.
It doesn't work that way. Malware today is a profit driven business. As of now, it doesn't make business sense to develop malware for OSX.

Re:Doesn't matter (2, Informative)

piojo (995934) | more than 6 years ago | (#23119214)

And you can't hide what the patch fixes.
Actually, I disagree. What if Microsoft obfuscated or encrypted executables the same way that (I've heard) Apple does? Then, any vulnerable executable could be fixed and re-encrypted, and the diff between the two versions would just look like garbage. To get the real data, one would need to break the (obfuscation-based) encryption, but that would take a few weeks (plenty of time for everyone that cares to patch themselves). This depends on Microsoft changing the encryption scheme frequently, like Apple does with iTunes.

Re:Doesn't matter (2, Insightful)

OzPeter (195038) | more than 6 years ago | (#23119408)

How about image fresh system, apply patches, compare result with fresh system? No need to break encryption at all.

The only way you can stop this is if all system data was encrypted and the user was not trusted with the keys to decrypt.

Now where have I heard that before??? Hmmm .. TPM anyone?

Re:Doesn't matter (1)

PoderOmega (677170) | more than 6 years ago | (#23119588)

But if Microsoft did that, how would we find all their undocumented API calls?

If the executable and libraries all run in memory encrypted or unencrypted wouldn't you be able to tell what the patch changed by comparing an unpatched versus patched process in memory? It would obviously be more difficult because the executable would actually have to be used in a method that the patch affected.

Re:Doesn't matter (2, Interesting)

Ed Avis (5917) | more than 6 years ago | (#23119308)

You can certainly distribute the patch synchronously to 99% of the PCs (the other 1% being those not connected to the Internet or with broken auto-update). 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. Clients could even distribute the key among themselves peer-to-peer. The bigger problem is the timelag between the patch being revealed to the world and the machine starting to run the upgraded version of the software (which often requires a reboot). It might be necessary for patches to contain instructions saying to stop the vulnerable service immediately and not bring it back up until the new code is installed.

However, would such a scheme be compatible with free software? Under the GPL, would a Linux distributor be permitted to send out encrypted binary patches and only reveal the decryption key later?

Re:Doesn't matter (1)

cbart387 (1192883) | more than 6 years ago | (#23119388)

The bigger problem is the timelag between the patch being revealed to the world and the machine starting to run the upgraded version of the software (which often requires a reboot).
That brings up a good point that I wonder if anyone has an answer to. Why is it that all windows updates require a reboot but very few linux updates do?

Re:Doesn't matter (5, Insightful)

Sancho (17056) | more than 6 years ago | (#23119618)

You can't overwrite a file that's in use by Windows. You can overwrite a file that's in use by Linux. The old image is still there. Any new processes loading the file will get the new version, and any old processes which still have a file handle to the old file get to use the old image.
I don't know if that's the whole reason, but I bet that it's part of it.

Re:Doesn't matter (1)

What Would NPH Do (1274934) | more than 6 years ago | (#23119664)

Well then don't you think it would just be better that the update would just restart the relevant processes rather than making you completely reboot? That would make more sense to me...

Re:Doesn't matter (1)

cbart387 (1192883) | more than 6 years ago | (#23119726)

That's what I would think, and perhaps I should have clarified. I understand why/how linux is able to update processes without shutting down the whole system. I'm just perplexed as to why Windows doesn't/can't do the same. Perhaps it's just a simple matter of poor engineering (or lack thereof).

Re:Doesn't matter (1, Redundant)

What Would NPH Do (1274934) | more than 6 years ago | (#23119622)

Because in Linux you only need to reboot if you're messing around in the kernel. Everything else can be patched and then restarted. Why Windows needs to reboot for something that isn't kernel related is rather odd to me.

Re:Doesn't matter (0)

Anonymous Coward | more than 6 years ago | (#23119744)

Why is it that all windows updates require a reboot but very few linux updates do?

In windows you cannot replace used (locked) files. What the update does is create fixed copy of the used file, which replaces the locked copy on reboot. In Linux, you can delete a file without affecting programs using it, as long as those programs have an open file descriptor to it. The fixed file is put in place and any new program will benefit from the fix. The programs that ran before the fix will have to be restarted.
I am not sure how updating kernel works, though.

Re:Doesn't matter (1)

ShieldW0lf (601553) | more than 6 years ago | (#23119602)

That's a really smart idea. Someone mod this guy up.

Re:Doesn't matter (1)

MrKahuna (789335) | more than 6 years ago | (#23120060)

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.
How would you ever know when "all" the clients have downloaded it? How would you know when the LAST person downloaded it? Do we all have to wait for that one person on a 300 baud solar powered modem living under a rock in a cave? There's no way to totally eliminate this problem via the patch delivery mechanism. Things like Steam work because there's a defined public release date and many people willing to download it in advance. However there are also many people who download after the release date.

Re:Doesn't matter (1)

Ed Avis (5917) | more than 6 years ago | (#23120226)

One way is to make systems start up in a restricted mode where all they can do is connect to the update server and check they have all the latest security patches. That way, systems that were switched off when the update was announced will catch up on the next boot.

Patches could be in two parts: the first part just says what service is affected (and should thus be shut down until patched), and the second part contain the actual code. Even hosts on slow network connections would be able to get the first part of the patch, and once the key is revealed to the world, shut down the vulnerable service. It wouldn't restart until the new code was downloaded and installed.

You are right that you could never get 100% coverage. But it would certainly help reduce the window of vulnerability from several days to a few seconds. That still might not be enough.

Re:Doesn't matter (1)

JustinOpinion (1246824) | more than 6 years ago | (#23119502)

You can never distribute patches synchronously to all the PC:s in the world.
Maybe you could.

Consider that a patch is first distributed as an encrypted file. The decryption key is kept secret until everyone has a chance to download the patch. At a pre-determined time, the decryption key is transmitted to everyone (the key is quite small so everyone getting it at nearly the same time shouldn't overwhelm the distribution server; a simplistic multicast or tree-like distribution system (like NTP) could further alleviate this problem). So then every computer patches itself at more-or-less the same time.

To prevent any attacks during the short window while systems are patching themselves, the protocol could be: download key; shutdown network; decrypt patch; apply patch; restart network.

This system, of course, introduces its own problems. For one thing, many organizations are not going to trust new patches without testing them first. The additional complexity may not be worth the effort, especially considering that the real problem here is that people in general don't keep their systems up-to-date.

Re:Doesn't matter (1)

silvaran (214334) | more than 6 years ago | (#23119658)

How about distributing them encrypted over the course of days or weeks, and then releasing a decryption key (pretty minuscule by comparison) once distribution volumes are sufficiently high?

Re:Doesn't matter (1)

Opportunist (166417) | more than 6 years ago | (#23119874)

Not really. You can distribute fixes asynchronously while still retaining security. But it would require the user to first of all determine when, how and what is to be fixed, and of course the ability to check the fix.

Easy with OSS, I have no idea how MS is supposed to do it, though.

No prob... (2, Funny)

Last_Available_Usern (756093) | more than 6 years ago | (#23119058)

Just roll the entire i386 directory into every patch.

Re:No prob... (1)

Sancho (17056) | more than 6 years ago | (#23119190)

Because it's not trivial to do a diff to find out which files changed.

It'd take a lot longer, and be only slightly harder, if all of the binaries were encrypted. They've still got to run, though, so the images have to be available in memory.

Re:No prob... (1)

Vectronic (1221470) | more than 6 years ago | (#23119272)

First of all, the i386 directory only exists on Windows 2000 and before (or unless upgraded from one of those OS')..unless you meant %systemroot% = i386

Secondly, Windows (and most if not all other OS')..doesnt limit its Update to the Windows directory or sub directories... what about Program Files, Common Files, User Directory...registry...etc.

Thirdly, this doesnt "fix" anything unless you consider increased network traffic a fix...

Generally people who are looking for "whats changed" dont limit their scan to the Modified Date... because the Modified Date can be "Modified"...

Binary comparison (or similar) is what shows the differences, and then disassembly, etc... and with a decent computer you can scan GB's of files for comparisons relatively quickly... so "they" are going to find out what changed anyways...

Re:No prob... (1)

Last_Available_Usern (756093) | more than 6 years ago | (#23119366)

*Sigh* It's become pretty obvious on these forums that intelligence and sarcasm detection are indirectly proportional attributes.

Re:No prob... (1)

Sancho (17056) | more than 6 years ago | (#23119640)

Maybe to some degree, but my fear is that some system developer will read that, think, "Hey, that's a great idea!" and add it to their patch management system.

Worst possible way to critize Windows Updates (4, Insightful)

pembo13 (770295) | more than 6 years ago | (#23119076)

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.

That's the biggest problem. (1)

khasim (1285) | more than 6 years ago | (#23119158)

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.

Re:Worst possible way to critize Windows Updates (1)

Last_Available_Usern (756093) | more than 6 years ago | (#23119188)

Not really a solution, but more public focus on upcoming vulnerability patches would be helpful. And I don't mean in the sense of *what* the vulnerability is, but moreso that it's coming, and how important it is. As it stands now, everyone is so familiar with "patch tuesday" that's as much an after-thought as a new moon. If we gave each cycle (or at least really important ones) the importance of an eclipse, we might get somewhere. This could be achieved through MS helping us understand the importance of an upcoming release without necessarily divulging all the details of it. When a boss knows the importance of a patch before it's released (even if he doesn't understand *what* it fixes), the IT staff is much less-likely to allow that vulnerability to go unmitigated as their ability to bullshit their way through damage control after-the-fact has gone out the window.

Re:Worst possible way to critize Windows Updates (1)

Tontoman (737489) | more than 6 years ago | (#23119194)

They could encrypt their OS (and patches) with Windows Media DRM. Then it would be illegal to decrypt and backwards-engineer the patches. The RIAA would enforce.

Re:Worst possible way to critize Windows Updates (1)

Opportunist (166417) | more than 6 years ago | (#23120024)

But remember, in Soviet Russia, law enforces YOU!

In other words, try to enforce something in a country that doesn't care about your problems, since it has its own.

Re:Worst possible way to critize Windows Updates (1)

evanbd (210358) | more than 6 years ago | (#23119450)

If I have it set to auto-update as soon as the update is available, it's hard to argue I'm being irresponsible. If it takes longer to get the update to everyone than it takes the attacker to create a new exploit, that's a problem -- and not one that users can solve.

Re:Worst possible way to critize Windows Updates (1)

corsec67 (627446) | more than 6 years ago | (#23119666)

The problem with instant auto-update, is that patches that wreck your system get applied instantly.

And then what about updates that need a reboot? Should that be automatic and instant?

This is a very hard problem, with no easy answer aside from "build it with security from the ground up"

Re:Worst possible way to critize Windows Updates (1)

evanbd (210358) | more than 6 years ago | (#23120144)

Most users turn on auto-update; instant doesn't add any downsides. If you're worried about that, then you need to do your job as a sysadmin, and this wouldn't change anything there either (since you'd have auto-update turned off in either case). Things requiring a reboot would be handled however they are currently -- just with less latency between the patch being available and everyone having it.

You're right, of course, that there is no easy answer.

Re:Worst possible way to critize Windows Updates (1)

RonnyJ (651856) | more than 6 years ago | (#23119490)

The silly thing is, it's even easier to research how vulnerabilities would work on unpatched systems for open-source software - you don't need to examine the patch, you have access to the changes in the source code!

Re:Worst possible way to critize Windows Updates (5, Insightful)

realthing02 (1084767) | more than 6 years ago | (#23120000)

I think you actually missed the worst part about this summary (not the article...)

From the summary: "Such as Windows Update... can detract from overall security, and should be redesigned."

The ellipse represents 14 pages of information in this sentence. And the Actual PDF doesn't say it detracts from security, but rather that the scheme is insecure. Which is quite a difference. Normally I don't do this, but the quote is really stupid when put the way the contributor or editor put in there. The article was interesting enough on its own accord (automatic patch-exploit generation) without having to throw your own personal cracks in there.

Let's grow up, people.

update this, fuckers (5, Insightful)

Anonymous Coward | more than 6 years ago | (#23119086)

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.

Re:update this, fuckers (4, Insightful)

somersault (912633) | more than 6 years ago | (#23119516)

Meh, don't come crying to me when some guy in [insert-evil-country-here] steals your identity, uses it to buy a few Porsche's and setup illegal goat kid porn themed websites in your name. You keep making your messes, I'm happy to make $50000 a year cleaning them up as long as it doesn't happen more than two or three times a year..

Re:update this, fuckers (1)

Opportunist (166417) | more than 6 years ago | (#23120066)

(shrug)

I don't mind being a 70k a year janitor. Dunno if it would be cheaper to just not make a mess, but hey, I certainly won't complain about it. Every time your computer barfs, my cash register jingles.

Re:update this, fuckers (1)

alx5000 (896642) | more than 6 years ago | (#23120210)

In my case, I seriously doubt they'd even get a Porsche's seat-belt...

Windows bashing aside ... (4, Insightful)

utnapistim (931738) | more than 6 years ago | (#23119104)

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

Re:Windows bashing aside ... (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23119318)

Somebody please correct me if I'm mistaken.

No.

Your ignorance is amusing.

Re:Windows bashing aside ... (2, Insightful)

Kjella (173770) | more than 6 years ago | (#23119336)

Right, in fact this probably indicates that patch tuesday [wikipedia.org] may not be a bad thing because then at least every admin worth his salt knows that's the time to update the systems. With patches coming in almost daily on Linux, you either have constant patch duty or it's a lot more staggered already. That's assuming you actually do something with the patches and don't just auto-apply everything, in which case I guess it doesn't matter. But, let's try to make everything with an anti-microsoft spin shall we?

Re:Windows bashing aside ... (1)

Craig Maloney (1104) | more than 6 years ago | (#23119354)

That was my understanding as well. There will always be a lag time between discovering and patching a flaw. 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.

Re:Windows bashing aside ... (2, Insightful)

phantomfive (622387) | more than 6 years ago | (#23119454)

Kernels are usually distributed as binaries, but in general other software is distributed by source. Of course, different distros do it differently.

However, the fact that you can obtain the code makes no difference, and may even be a hinderance, since an exploit can be created here in as little as a minute just from the binaries.

The major difference here between Windows and Linux is that Windows is a lot more of a mono-culture. In the linux world, there is no guarantee that an exploit will be available the same way. It is also unlikely that two different distributions have the same binaries. In fact, different computers using the same distro can end up with different binaries.

Realistically, an exploit is bad. This research is just a way to make a bad thing worse.

Re:Windows bashing aside ... (0)

Anonymous Coward | more than 6 years ago | (#23119556)

... patch based security is also the model linux uses (as far as I understand).

Ugh.. Why are people like you allowed on the internet!

Read the article. Hell, read the damn slashdot summary: "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"

Given: Linux doesn't stagger patch distribution. MS does. Conclusion: There is a weakness in MS patch distribution that doesn't exist in Linux.

Re:Windows bashing aside ... (1)

Wrath0fb0b (302444) | more than 6 years ago | (#23119598)

The OP is correct, Linux updates (at least in the *untu line of distros) are purposefully staggered to avoid hammering the servers. IIRC, every install has a random number associated with it that determines when it checks for and grabs the updates.

As others have said, there's nothing you can do about it except hope that there are multiple layers of security (I suppose compartmentalization and frequent backups help in the remedial sense).

Where's the WellDuh Tag (1)

techpawn (969834) | more than 6 years ago | (#23119164)

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.

Re:Where's the WellDuh Tag (2, Informative)

Bacon Bits (926911) | more than 6 years ago | (#23120096)

Yeah, exactly. If this is a problem with Windows, then it's a worse problem with Linux!

Not only can you reverse engineer the binary, but you have access to the source code and it's modifications. If you read bug trackers or dev mailing lists, you can even pick up security vulnerabilities before the patch is even released just by looking at bugs and diff files.

You can't put the toothpaste back in the tube, people. Arguing that that means you shouldn't brush your teeth is ridiculous.

M$ need to stop haveing a fixed update day and go (1)

Joe The Dragon (967727) | more than 6 years ago | (#23119208)

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.

Black Tuesday Has Value (1)

FurtiveGlancer (1274746) | more than 6 years ago | (#23119770)

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 [sans.org]

Instant patching is never going to happen. (3, Informative)

Vellmont (569020) | more than 6 years ago | (#23119220)

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.

Requires administrative privileges to apply (0)

ClubStew (113954) | more than 6 years ago | (#23119296)

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.

Re:Requires administrative privileges to apply (1)

Sancho (17056) | more than 6 years ago | (#23119692)

I think you really missed the point. This has nothing to do with being admin on a vulnerable machine or "generating a vulnerability."

The point is that on my own machine, I can examine the patch and the old file, and then generate an exploit. If the vulnerability was in a running service (say, the firewall code or the Server service), then I can create a worm which will propagate through the network.

Windows Update Can Hurt Security (0, Flamebait)

onefriedrice (1171917) | more than 6 years ago | (#23119322)

Wow. Who knew?

How is this limited to Windows? (4, Insightful)

analog_line (465182) | more than 6 years ago | (#23119324)

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.

From the PDF: (4, Informative)

TripMaster Monkey (862126) | more than 6 years ago | (#23119344)

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.

Another problem with strategy 2 (1)

symbolset (646467) | more than 6 years ago | (#23119792)

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.

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.

Re:From the PDF: (2, Funny)

Seth Kriticos (1227934) | more than 6 years ago | (#23120176)

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.

Why not use the bot nets for this kind of stuff? I mean, previous article today already showed, that they have a quite effective way of patching arbitrary systems and distribute mass content.

Problem is much bigger than article suggests (0)

Anonymous Coward | more than 6 years ago | (#23119362)

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.

No fix feasible (4, Interesting)

Todd Knarr (15451) | more than 6 years ago | (#23119386)

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.

So what would the new system look like? (1)

evanbd (210358) | more than 6 years ago | (#23119394)

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.

This article is dumb. (3, Interesting)

Mongoose Disciple (722373) | more than 6 years ago | (#23119414)

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

Re:This article is dumb. (2, Informative)

TripMaster Monkey (862126) | more than 6 years ago | (#23119656)

Didn't actually RTFA, did you?

If you had, you'd know that this paper did not say that "hackers can analyze Windows Updates and figure out how to attack systems that aren't patched yet thereby". What it did say was that it is possible to write software that can analyze the update for you and churn out an exploit for the security issue identified thereby...in a matter of seconds.

There is a solution... (0)

thatskinnyguy (1129515) | more than 6 years ago | (#23119484)

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

Staggered patch distribution is VERY imporant (1, Redundant)

Thornburg (264444) | more than 6 years ago | (#23119682)

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.

Re:Staggered patch distribution is VERY imporant (1)

TripMaster Monkey (862126) | more than 6 years ago | (#23119748)

What would happen if every single Windows box in the entire world simultaneously lost all network connectivity?

Something like this [gawker.com] , I would imagine... ^_^

Windows can hurt security (1)

Akita24 (1080779) | more than 6 years ago | (#23119712)

There, fixed that for you. (Sorry, couldn't resist)

Automatically deriving exploits by theorem proving (5, Informative)

Animats (122034) | more than 6 years ago | (#23119884)

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.

Ok, it's bad. Got any better ideas? (4, Insightful)

Opportunist (166417) | more than 6 years ago | (#23120138)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?