×

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!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

160 comments

Hope it just leaks lots of data (1)

h00manist (800926) | more than 3 years ago | (#34245556)

That's the best use I can visualize for virii and rootkits

Re:Hope it just leaks lots of data (0)

Anonymous Coward | more than 3 years ago | (#34245624)

Virii? Holy shit, is it 1994?

Re:Hope it just leaks lots of data (0)

Anonymous Coward | more than 3 years ago | (#34245714)

What people need to realise :

"Boxen" sounds silly and affected but at least everyone sees that it's deliberate.

"Virii" makes people wonder whether you really think that's the right word.

Acceptable and Proper Slashdot Vocabulary (2, Funny)

h00manist (800926) | more than 3 years ago | (#34246094)

Welcome to Eleven Thousandth Slash Dot Dot Org's and Cambridge International Language Forum! We shall henceforth debate the propriety of linguistic terms to be used by ourselves, and other participants of the public at large, within the realm of our debate on all matters relating to the technical world - including those of impact in non-technically-literate circles of society. We will here discuss the proper use of verbs and nouns, adverbs and adjectives, phrasal verbs and colloquial terms, and vote on their acceptability to be assembled into a properly approved vocabulary for use on this most honourable forum in all of geekdom, Slashdot! Our first items approved on the agenda today -

Acceptable vocabulary for use within Slashdot fora

boxen, facetious plural of box (by analogy to oxen as the plural form of ox), particularly in computer hacker slang with respect to the term 'box' for a computer

Non-acceptable vocabulary for use within Slashdot fora

Virii is in fact an INCORRECT pluralization of "virus", however, some retard keeps resubmitting it as the plural form. 1 4m k00l, 1 c4n wr173 l33tz0r 'virii' 1n v15u4l b451c 5cr1p7.. ph33r m3h.

Further submissions for today's Slashdot Approved Vocabulary vote?

Re:Acceptable and Proper Slashdot Vocabulary (1)

PRMan (959735) | more than 3 years ago | (#34246420)

boxen is wayyy stupider than virii.

Re:Acceptable and Proper Slashdot Vocabulary (0)

Anonymous Coward | more than 3 years ago | (#34246842)

No, "boxen" is meant to be humorous. "Virii" is someone trying to appear smarter than he really is.

Re:Acceptable and Proper Slashdot Vocabulary (0)

Anonymous Coward | more than 3 years ago | (#34246868)

Or has too many "I"'s while playing scrabble and insists it's a real word.

Re:Acceptable and Proper Slashdot Vocabulary (0)

Anonymous Coward | more than 3 years ago | (#34247074)

No, what is stupid is thinking "stupider" is an actual word.

Re:Acceptable and Proper Slashdot Vocabulary (5, Insightful)

hairyfeet (841228) | more than 3 years ago | (#34249032)

I don't know, that is kinda like arguing you are the tallest midget as BOTH are major levels of stupid.

As for TFA, as long as Windows is the #1 desktop deployed it will always be a target, but frankly as a PC repairman I can say there is so much low hanging fruit with home users most won't even need this trick. All they have to do is pop up on a website "ZOMG DUDE, You got teh Viruz!! Turn off yur broken AV and run this ZOMG quick!!!" and you'd be surprised how many will do JUST that. I have literally sat beside a user and said "Do NOT open a password protected zip file it IS a virus!" and had them go "My BFF Kim sent this! stop being paranoid!" and watched dumbfounded as they proceeded to do EXACTLY what the instructions said and pwned themselves.

While I'm sure the malware kits will all add this to make guys like me have to work harder to get rid of it (in actuality it is pretty much nuke and reinstall anymore) to actually infect many home users all you have to do is the above or the ever easy "You need this codec to watch our FREE Lesbian pron!". I swear guys fall for THAT one damned near every time. I actually had to hunt down a decent virus free porn site just to send my "must click teh prons!" users to just to keep them from constantly reinfecting their machines.

So Linux guys be DAMNED GLAD you don't have those home users and there will hopefully NEVER be a "year of the Linux desktop" because a week later the net will be flooded with "Porn_Codec.sh" and "Happy_Puppy.scr.sh"with helpful instructions on how to run them that the users WILL follow. Stupid is as Stupid Does.

Re:Acceptable and Proper Slashdot Vocabulary (1)

Mister Pedant (1722084) | more than 3 years ago | (#34249162)

shouldn't it (in the new muchy muchy improved version internety english) read:
'boxen is wayyy stupider then virii.'

Re:Acceptable and Proper Slashdot Vocabulary (0)

Anonymous Coward | more than 3 years ago | (#34247890)

'Box', hacker slang with respect to the term box for a computer. Wouldn't it make sense that the plural is 'boxers' then?

Re:Hope it just leaks lots of data (3, Interesting)

afidel (530433) | more than 3 years ago | (#34246802)

Actually, the best use is to install drivers that bypass DRM.

Once and for all... (2, Informative)

WaroDaBeast (1211048) | more than 3 years ago | (#34247700)

The nominative plural ending for Latin nouns following the second declension is -i, so if virus was a masculine noun, which it is not [wikipedia.org] ("n." means it's neutral), it would then take an i, which would give "viri." But since "virus" is neutral, its plural is "vira," so next time you wanna brag about how well you know Latin — without sounding like a fool —, say that instead.

Or you can say "viruses" if you feel like speaking English. My €0.02.


P.S.: The only time you get that double i in the nominative plural is when you inflect a second declension masculine noun that ends in -ius, such as "filius."

Well, DUH... (2, Insightful)

adjuster (61096) | more than 3 years ago | (#34245598)

Without "trusted" hardware the user will always be able to override software "protections" designed to prevent arbitrary code execution. This is just another "leapfrog" in this arms race. Give me "trusted computing" where I control the keys and decide what software is "trusted" and I'd be fine w/ it. Otherwise, I'll take the current situation on personal computers because, at least, I can run arbitrary software. ("Don't turn my PC into an iPhone, bro!")

Re:Well, DUH... (4, Informative)

tompaulco (629533) | more than 3 years ago | (#34245786)

Code signing is just a money making scheme for Microsoft cleverly disguised as a protective measure for us users. Smaller projects can not afford to have their code digitally signed by Microsoft. People have been writing workarounds for this involving spoofing the driver as being in TEST mode, but this is a hassle for the end user.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34246598)

Parent is NOT a troll, he's absolutely correct.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34247774)

Umm no he's not - code signing and driver signing != and he confuses them badly.

Re:Well, DUH... (2, Informative)

Applekid (993327) | more than 3 years ago | (#34247164)

Code signing is just a money making scheme for Microsoft cleverly disguised as a protective measure for us users. Smaller projects can not afford to have their code digitally signed by Microsoft. People have been writing workarounds for this involving spoofing the driver as being in TEST mode, but this is a hassle for the end user.

Um, code signing can be by any trusted authority. You need not pay Microsoft for user code.

Drivers are another story. They need to pass WHQL, but that's no big deal because it's already paid through the licensing fees collected if you want to put a Windows logo on your product certifying it's compatible with Windows. Naturally, if it's going to have the logo on the box, Microsoft wants to make sure your crappy driver doesn't cause problems that will be blamed on Windows.

Installing unsigned drivers in testing mode is a pain in a live environment for the same very good reason you don't want to perform crash testing on a live motorway.

Re:Well, DUH... (2, Interesting)

rsmith-mac (639075) | more than 3 years ago | (#34249538)

Drivers are another story. They need to pass WHQL

Even this is not quite true. There are 2 different levels of signing: Ownership signing, and WHQL signing. Ownership signing establishes who the driver came from; unless a driver is ownership signed, 64bit versions of Windows will flat-out refuse to install it (unless you boot with signature enforcement disabled) and is what TFA is referencing. WHQL signing is a second layer where MS signs off on the drver; without a WHQL signature, Windows will throw up a scary warning advising you that the driver is not WHQL signed and that you should not install it, but it will still let you install the driver if you choose to. The only other non-WHQL limitation is that Windows won't use the driver automatically for newly installed devices.

In any case, drivers ultimately do not need to pass WHQL to be used. Ownership signing is sufficient to allow installation, however any serious vendor is going to want WHQL approval to avoid the scary warning.

Re:Well, DUH... (3, Interesting)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34245814)

Give me "trusted computing" where I control the keys and decide what software is "trusted" and I'd be fine w/ it.

The problem is, 99% of our society cannot properly decide whether software should be trusted or not, and even with more granular controls and proper feedback from the OS a lot of malware will slip through.

I don't think this is an unsolvable problem. I like the iPhone App store model to some extent. A company with professionals should be vetting software and should be telling users what software should and should not be able to run. But the iPhone App store fails in many ways as well.

First, there should not be one company deciding. We should harness the free market and build a system that takes inputs from whatever security feeds users subscribe to and weight those security feeds based upon the end user's preferences. Also, we should be able to override the choices for any given case. If we really want to run some software but our security feeds think it is malware, we should be able to do it. Heck, there are valid reasons, such as research, for wanting to run malware. It should just be a very advanced setting that makes it perfectly clear to the end user that they're handing complete control of their device to some other party, forever.

I'm convinced we could leverage the benefits of both an iPhone app store approach and a traditional package manager approach. I fear, however, that none of the companies in a position to actually make a good system and push it to end users is going to be motivated to do so. Apple will wait for others, and Microsoft sees the way they could leverage their monopoly using an iApp store of their own. Canonical has laid the groundwork, but only as far as copying Apple and incorporating it into their package manager. They're not much for making revolutionary new technologies, nor are they in much position to push it and, lastly, unless they're aiming at the ultra-secure market, their users are currently least in the need of beefing up security.

Re:Well, DUH... (1)

sexconker (1179573) | more than 3 years ago | (#34245984)

The problem is, 99% of our society cannot properly decide whether software should be trusted or not, and even with more granular controls and proper feedback from the OS a lot of malware will slip through.

The problem is 99% of society.
The solution is to not trust them with any power or responsibility when it comes to our computer systems.

No, office drone, you do not need administrator rights.
No, pointy-haired-boss, I'm not installing an unsigned driver for the shitty business-card scanner you got as a gift.
No, family, I will not hunt down a hacked driver for your 15 year old printer so you can use it on Windows 7 64-bit.

Re:Well, DUH... (1)

Pharmboy (216950) | more than 3 years ago | (#34248452)

No, office drone, you do not need administrator rights.
No, pointy-haired-boss, I'm not installing an unsigned driver for the shitty business-card scanner you got as a gift.
No, family, I will not hunt down a hacked driver for your 15 year old printer so you can use it on Windows 7 64-bit.

So you are pretty much alienated from your family and unemployed for being a dick now?

Re:Well, DUH... (3, Interesting)

TheLink (130905) | more than 3 years ago | (#34245998)

A company with professionals should be vetting software and should be telling users what software should and should not be able to run.

IMO, the software should be saying what type of sandbox it wants upfront. From a finite manageable set of sandbox templates.

The software could also instead request a custom sandbox, but a "custom sandbox and app pair" need to be signed by a trusted party. Either the OS vendor, or someone else with their cert installed (e.g. Corporate IT).

I proposed something like this to Ubuntu: https://bugs.launchpad.net/ubuntu/+bug/156693 [launchpad.net]

Rather than solve something harder than the halting problem (you often don't have the full inputs to the program), you just get the programmers to declare upfront what access the programs need, and if declared OK, the OS enforces the sandboxes.

Re:Well, DUH... (2, Interesting)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34248922)

IMO, the software should be saying what type of sandbox it wants upfront. From a finite manageable set of sandbox templates.

Agreed. It greatly lessens the work for auditors as they only have to figure out what you're doing with the services/access and then decide if that is actually appropriate. I'd also mention adding official services and protocols (such as an update service, a secure registration/purchasing service, a service for ad streaming to supported apps, etc.) results in fewer apps needing to roll their own services for these purposes and further simplifies security auditing.

Re:Well, DUH... (2, Insightful)

TemporalBeing (803363) | more than 3 years ago | (#34246184)

Give me "trusted computing" where I control the keys and decide what software is "trusted" and I'd be fine w/ it.

The problem is, 99% of our society cannot properly decide whether software should be trusted or not, and even with more granular controls and proper feedback from the OS a lot of malware will slip through.

I don't think this is an unsolvable problem.

But how that 99% of society wants to use the computer should not ( and cannot necessarily) be dictated by even the 1% as the 1% will not know every edge case for how the 99% wants to use the computer. Thereby, "trusted" computing in that model is 100% flawed, and you then have to build in backdoors - like the register key that can disable requiring a signed driver so developers can test their drivers - so that the 99% can all do what they want/need to on the computer.

Re:Well, DUH... (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34248974)

But how that 99% of society wants to use the computer should not ( and cannot necessarily) be dictated by even the 1% as the 1% will not know every edge case for how the 99% wants to use the computer.

Actually 99% of users will probably never do anything that would even be an issue. Malware primarily runs because users are not informed by the OS that it is malware or told that it is accessing their address book and starting a mail server or constantly spamming traffic at an address in Estonia. For the other 1% of cases the user needs the option to override the security system, but this should never be needed for normal use cases so when an app requests this it should be a red flag to users. Right now they're so conditioned by our poor OS UIs they just click through things. But if a users was never, ever (over the course of owning a machine and later over their lifetime) asked o override security and they were asked at some point with language worded to say doing so would allow someone else control of their computer forever, I think that would make a huge difference, don't you?

Re:Well, DUH... (1)

thoth (7907) | more than 3 years ago | (#34246548)

First, there should not be one company deciding. We should harness the free market and build a system that takes inputs from whatever security feeds users subscribe to and weight those security feeds based upon the end user's preferences.

There isn't one company deciding, right? If you don't like vendor X, move to vendor Y. Free market behavior doesn't guarantee your issue is solved on the platform of your choice - maybe some other vendor is addressing your concern (if it is profitable and so on for them to do so, generally meaning your concern is valid to a large enough group the vendor may actually care) and deserves your business. Currently, people who don't care enough about this and proxy their decisions to the vendor (i.e. Apple), purchase the vendor's (i.e. Apple's) goods. People who do care settle for whatever else is out there that most fits their needs, or withhold their purchasing. The free market doesn't guarantee everybody is maximally satisfied with the available goods.

I'm convinced we could leverage the benefits of both an iPhone app store approach and a traditional package manager approach. I fear, however, that none of the companies in a position to actually make a good system and push it to end users is going to be motivated to do so.

Isn't this a valid manifestation of the free market? Free market behavior doesn't guarantee the outcome you want.

Re:Well, DUH... (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34249024)

First, there should not be one company deciding. We should harness the free market and build a system that takes inputs from whatever security feeds users subscribe to and weight those security feeds based upon the end user's preferences.

There isn't one company deciding, right? If you don't like vendor X, move to vendor Y.

Except at least for PC's, this is an OS level problem and desktop OS's are a monopolized market. But I'm not making any claims about what has to happen, just what would be best for end users in my opinion. Obviously having to switch OS's in order to change security feeds would be less than ideal for users. and would lessen the ability of the free market to bring those users benefits.

I'm convinced we could leverage the benefits of both an iPhone app store approach and a traditional package manager approach. I fear, however, that none of the companies in a position to actually make a good system and push it to end users is going to be motivated to do so.

Isn't this a valid manifestation of the free market?

If i were a free market, perhaps. But the courts in at least four countries I know of have already ruled that the free market is not acting appropriately and that a monopoly has formed in the desktop OS market. It's pretty clear that MS's Windows market share will hold back progress significantly and the free market breaks when it encounters a monopoly (which is why we have antitrust/competition laws).

Re:Well, DUH... (1)

orange47 (1519059) | more than 3 years ago | (#34247668)

We should harness the free market and build a system that takes inputs from whatever security feeds users subscribe to and weight those security feeds based upon the end user's preferences. Also, we should be able to override the choices for any given case.

I think they have a good system at http://www.virustotal.com/ [virustotal.com] users have ratings and leave comments. too bad it wouldn't work for large files. but we could use hashes for them.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34247828)

And that company with professionals leaked a tethering app in a flashlight app. What's that say about the minimum wage grunts^H^H^H^H software professionals ability to scan for malware in a compiled binary? Thankfully apps on that device are extremely limited as to what they can access due to the sandboxing -- the app can't even request for additional permissions, as there is on Android or Blackberry).

To be perfectly honest, nobody has any idea if even professional software like AutoCAD, Windows, M acOS, etc are calling home, reporting user information. All the end user is given is compiled MB/GB of data, any one of which could secretly hide a data connection.

Re:Well, DUH... (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34249082)

And that company with professionals leaked a tethering app in a flashlight app. What's that say about the minimum wage grunts^H^H^H^H software professionals ability to scan for malware in a compiled binary? Thankfully apps on that device are extremely limited as to what they can access due to the sandboxing -- the app can't even request for additional permissions, as there is on Android or Blackberry).

Sandboxing and declared ACLs can help, but what you bring up is why it would be nice to bring competition to the space. By letting users pick and weight various security feeds, you don't have to rely on Apple (for example). Instead you could get a feed from an open source project as well and from a dedicated security company that just does audits. Remember even if it is a compiled binary, the security experts can still see the sandbox ACL.

To be perfectly honest, nobody has any idea if even professional software like AutoCAD, Windows, M acOS, etc are calling home, reporting user information.

There are lots of network security people and government agencies that look for just these things. Some of them do have a good idea, but you make a point that no one can know for certain.

Re:Well, DUH... (1)

BLKMGK (34057) | more than 3 years ago | (#34247858)

Sorry, I wouldn't want a model where others tell me what I can and cannot run - for the same reason it pisses me off installing new AV software and then having to change a bunch of settings so it won't flag\delete all of the fun "security" products I keep around that are useful like port scanners. The vast amount of software out there would be pretty tough to cover too and as Apple and Android both have found it's tough to stop a programmer from building a program that does one thing while also doing some less friendly or allowed things. I don't want to have to rely on a third party to be honest but then I'm also not quite Joe Average computer user.

I honestly do not see a great solution for all of this but from a Windows standpoint I think they have made good progress and continue to slowly tune up the OS as attacks like this go after it. Not perfect for sure but it continues to improve I think. The signed drivers, DEP, ASLR, canaries, and other things raise the bar for sure.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34247982)

I don't think this is an unsolvable problem. I like the iPhone App store model to some extent. A company with professionals should be vetting software and should be telling users what software should and should not be able to run. But the iPhone App store fails in many ways as well.

There are a number of sites that semi-automatically gather meta data about software, run them through virus scanners and so on, and then put their findings on the web. They are not much help to people as they cannot tell which of these sites do a decent job at this, the sites may not have the particular software they are interested in, once any such site becomes sufficiently popular attackers would find ways around them, and so on.

(Captcha is "viruses" ...)

Re:Well, DUH... (1)

tlhIngan (30335) | more than 3 years ago | (#34248298)

First, there should not be one company deciding. We should harness the free market and build a system that takes inputs from whatever security feeds users subscribe to and weight those security feeds based upon the end user's preferences. Also, we should be able to override the choices for any given case. If we really want to run some software but our security feeds think it is malware, we should be able to do it. Heck, there are valid reasons, such as research, for wanting to run malware. It should just be a very advanced setting that makes it perfectly clear to the end user that they're handing complete control of their device to some other party, forever.

Bzzt, you fail. You're back to square one.

Remember all those jailbroken iPhones getting hacked because OpenSSH was installed with default passwords? Want to remember why? Joe User was just following blindly some tutorial on the web - "Open Cydia, search for OpenSSH and install opensshd, then run PuTTY and log in with root/alpine". UAC won't stop them, jailbreaking doesn't stop them, etc. The users will blindly follow any instruction to get what they want. Any roadblocks they will bypass.

Your "method of bypass" will result in the following steps:
To install SuperCoolApp, you have to do the following:
1) Run SuperCoolApp Installer
2) When it pops up the "SECURITY WARNING - This app is malware" dialog, click "Yes" (or however other method to bypass protection). This version of SuperCoolApp has been falsely detected as malware - there is no virus in SuperCoolApp, and never will be if you get it from us.
3) Wait for install to finish.
4) Run SuperCoolApp!

After all, how many of those XP "This driver is not signed!" dialogs have we clicked "OK" to instead of "Stop Installation"? The manuals say to click OK, and we do.

It's already pretty easy to do on Linux to get someone who has too little time on their hands to download software, reconfigure their Linux box to be insecure, and have them pwned. Just tell them enough how to add your repository of Linux packages and they'll blindly follow your instructions and even download whatever trojans you provide.

It is a pretty unsolvable problem. UAC and everything is great for those on the ball and understand when things should happen (UAC shouldn't popup in most cases, and if it suddenly does on some random file off the Internet, maybe it's best to click Cancel), but it's otherwise just another step the user goes through to get some program running. Most don't even know that they've just opened a huge security hole on their computer. And they'll keep doing it.

Re:Well, DUH... (1)

99BottlesOfBeerInMyF (813746) | more than 3 years ago | (#34249180)

Bzzt, you fail. You're back to square one. Remember all those jailbroken iPhones getting hacked because OpenSSH was installed with default passwords?

No. I remember A TINY NUMBER of jailbroken iPhones getting owned because a very small subset of users hacked their phones and an even smaller subset installed SSH but did not change the default password.

The example you cite has little or nothing to do with mainstream security. We're in a situation right now where people regularly have automated malware infecting their machines in large numbers. Low hanging fruit first.

It is a pretty unsolvable problem.

Not really. The first step is to make software installation and default configuration easy and simple for developers writing software, seciurity expert auditing software, and users actually installing it. Once users no longer have to jump through hoops to perform computing tasks, they question why they are asked to jump through hoops in one particular case (malware) or they just don't bother out of laziness.

UAC and everything is great for those on the ball and understand when things should happen (UAC shouldn't popup in most cases, and if it suddenly does on some random file off the Internet, maybe it's best to click Cancel), but it's otherwise just another step the user goes through to get some program running.

UAC has broken UI that results in huge security holes because the "experts" didn't bother to adequately test it before they deployed. They were a lot ore concerned with making sure they could blame security problems on users instead of actually making things more secure. The point of a good UI is to not get in the users way. Apple's store does a good job of that, but doesn't have the best security. What I propose would keep the same ease of use with users basically never seeing any prompts, but adding in a better mechanism for making sure those apps are secure and properly sandboxed.

It's important not to make the mistake of assuming because Microsoft did something terribly, it can't be done well. Microsoft often does things terribly.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34245852)

"New Rootkit Bypasses Windows Code-Signing Security"

No duh, Slashdot, if you've been rootkitted, any OS level security can be bypassed.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34246246)

"trusted computing" would just be another leapfrog. Until the holes were found. As at some point the decision to run is made and the decision gate will be attacked.

Re:Well, DUH... (0)

Anonymous Coward | more than 3 years ago | (#34246252)

You already can do this with Software Restriction Policies.

http://www.mechbgon.com/srp/

I have marked folders where executables are stored as read-only for normal users and read/write for admins. Then I deny execution rights for all other folders. Its a shame they only started exposing this functionality recently. This functionality has been built into NT design for ages. And I suppose even longer in Unix.

Re:Well, DUH... (1)

cbhacking (979169) | more than 3 years ago | (#34246854)

Actually, it sounds like there's already a mechanism that (sort of) protects against this. Using BitLocker (full drive encryption, Vista and up) with a TPM (Trusted Platform Module, a sealed chip that can store crypto keys and keeps a running checksum of CPU instructions) won't technically prevent you from getting infected, but it will make automatic unlock fail. Automatically unlocking a bitlocked drive (where "automatic" means anything short of manually entering an AES256 key) usually uses the TPM. However, if the bootup instruction sequence was modified, for example by modified MBR code, the TPM won't unlock. You can still enter a manual recovery key, but it would be suspicious to suddenly need to.

Note that this doesn't prevent dual-booting; you just need to chainload GRUB from the Windows bootloader so that if you boot straight to Windows the TPM doesn't freak out. Note also that you can have one or two additional forms of authentication past the TPM, such as a PIN/passphrase, or a physical device (flashdrive, smartcard, etc.) Just usign the TPM alone will prevent anybody from putting in an Ubuntu CD and booting it live to read your Windows volume, but it won't stop somebody from booting Windows normally, then getting past the login screen using Firewire (not a Windows vulnerability, just a really stupid partof the ieee1394 spec that requires DMA).

It's not a full "I hold all the keys and I decide what runs" but it's close.

Re:Well, DUH... (1)

Bryan3000000 (1356999) | more than 3 years ago | (#34247194)

As far as I know, that's how "trusted computing" has always been implemented. The trusted modules that Apple put in their computers for a brief period of time were not used by the OS - they were there for developers or enterprises to use in precisely the way you suggest. Turns out they never got used for much of anything. You'll find trusted modules in some server hardware. It's once again there for developers or enterprises to use as you suggest.

The fundamental problem is that in order to really implement what you suggest, it has to be done one of two ways - 1) by developers, for a specific application on specific hardware. This means it's not for consumers. 2) at the OS level, meaning that code signing has to be done or at least approved by the OS maker. I suppose you could also do this with a third-party repository, but that would simply shift to a different third party, leaving it outside of your personal control once again.

Trusted computing could perhaps technically be put into the OS and under the control of consumers. The problem there is that since consumers wouldn't know what to trust, it would provide no better protection than the status quo and would perhaps make things worse. So you have to either hand control to OS makers, or leave it in the hands of enterprises or developers, where it currently resides.

In other words, everything is as it should be. If you want such personal control for yourself, buy the hardware and do the development or package maintenance for all packages all by yourself. Or do it in an enterprise. Or perhaps form a cooperative to do all this work. Oh wait, that would once again be essentially moving to a third-party trusted repository system. There is no practicable way for you personally to get all the control and security you are asking for.

But can TDL4 bypass Safe Mode? (4, Funny)

digitaldc (879047) | more than 3 years ago | (#34245660)

Safe Mode is all I run nowadays.
I am just too scared to 'Start Windows Normally'

Re:But can TDL4 bypass Safe Mode? (1)

Java Pimp (98454) | more than 3 years ago | (#34245782)

The only thing that is really needed to get by windows driver signing is an exploitable flaw in an existing signed driver.

Re:But can TDL4 bypass Safe Mode? (4, Funny)

Monkeedude1212 (1560403) | more than 3 years ago | (#34245840)

It's weird, when I tried the "Last Known Good" configuration it booted up Windows 98!

Re:But can TDL4 bypass Safe Mode? (0)

Anonymous Coward | more than 3 years ago | (#34246746)

yawn.

Wow. Master Boot Record infectors. (1)

idontgno (624372) | more than 3 years ago | (#34245684)

Old sk00l. When was the last MBR infector seen in the wild? 2002? Most of this class are from the DOS era, fercryingoutloud.

Re:Wow. Master Boot Record infectors. (2, Informative)

PatPending (953482) | more than 3 years ago | (#34245822)

Old sk00l. When was the last MBR infector seen in the wild? 2002? Most of this class are from the DOS era, fercryingoutloud.

From the second paragraph of the fine article (emphasis added):

TDSS has been causing serious trouble for users for more than two years now, and is an example of a particularly pernicious type of rootkit that infects the master boot record of a PC. This type of malware often is referred to as a bootkit and can be extremely difficult to remove once it's detected. The older versions of TDSS--TDL1, TDL2 and TDL3--are detected by most antimalware suites now, but it's TDL4 that's the most problematic right now.

Re:Wow. Master Boot Record infectors. (3, Insightful)

sexconker (1179573) | more than 3 years ago | (#34246144)

Why does everything have to be a kit?
Rootkit. Okay.
Bootkit. I see what you did there.

Would a WoW hack that steals/sells your loot be a lootkit?

Would a viral advertising campaign that gets a bunch of douches to seek out 1930s era fashion for their high school proms be a zoot kit?

Would naughty chimney sweeps toss packages of dirt, grime, and grease down your chimney and call it a soot kit?

Is whatever drug / "treatment" the government uses on every former agent who goes public with stories about aliens called a coot kit?

Are those wooden owls you put out to scare other birds away from your crops a hoot kit?

Is the point of this post completely inconsequential, making the post a moot kit?

Re:Wow. Master Boot Record infectors. (1)

FrankieBaby1986 (1035596) | more than 3 years ago | (#34249670)

Is a package containing scotch, hookers, blackjack and natalie portman covered in hot grits called a woot kit?

Re:Wow. Master Boot Record infectors. (1)

TemporalBeing (803363) | more than 3 years ago | (#34246278)

Old sk00l. When was the last MBR infector seen in the wild? 2002? Most of this class are from the DOS era, fercryingoutloud.

From the second paragraph of the fine article (emphasis added):

TDSS has been causing serious trouble for users for more than two years now, and is an example of a particularly pernicious type of rootkit that infects the master boot record of a PC. This type of malware often is referred to as a bootkit and can be extremely difficult to remove once it's detected. The older versions of TDSS--TDL1, TDL2 and TDL3--are detected by most antimalware suites now, but it's TDL4 that's the most problematic right now.

Easy way to remove it: (1) turn on the computer, (2) load the hard drives into another computer, scan, and dis-infect without loading the software on the computer - it should be read-write without execution permission; and finally (3) reset the firmware on the devices, especially the motherboard, on the computer. (Typically just the motherboard; but there could be other devices too that may need it.). Put it back-together, boot up, and your infection free.

OR

You could just run Linux/BSD/etc to start with and not have to worry about it.

Re:Wow. Master Boot Record infectors. (0)

Anonymous Coward | more than 3 years ago | (#34246714)

Old sk00l. When was the last MBR infector seen in the wild? 2002? Most of this class are from the DOS era, fercryingoutloud.

From the second paragraph of the fine article (emphasis added):

TDSS has been causing serious trouble for users for more than two years now, and is an example of a particularly pernicious type of rootkit that infects the master boot record of a PC. This type of malware often is referred to as a bootkit and can be extremely difficult to remove once it's detected. The older versions of TDSS--TDL1, TDL2 and TDL3--are detected by most antimalware suites now, but it's TDL4 that's the most problematic right now.

Easy way to remove it: (1) turn on the computer, (2) load the hard drives into another computer, scan, and dis-infect without loading the software on the computer - it should be read-write without execution permission; and finally (3) reset the firmware on the devices, especially the motherboard, on the computer. (Typically just the motherboard; but there could be other devices too that may need it.). Put it back-together, boot up, and your infection free.

OR

You could just run Linux/BSD/etc to start with and not have to worry about it.

What a troll, you linux fan boys keep on liying to everyone (including yourselves) when say that Linux has no security issues. Any OS, any app has at least one security hole, no software is perfect, and it never will.

Re:Wow. Master Boot Record infectors. (1)

Mister Whirly (964219) | more than 3 years ago | (#34247582)

Yeah, you could do all that, or you could just use MBRFIX and be done with it. "Extremely difficult" - I don't really think so. Typing 6 letters from a command prompt isn't something I would categorize as "extremely difficult".

Re:Wow. Master Boot Record infectors. (1)

TemporalBeing (803363) | more than 3 years ago | (#34247844)

Yeah, you could do all that, or you could just use MBRFIX and be done with it. "Extremely difficult" - I don't really think so. Typing 6 letters from a command prompt isn't something I would categorize as "extremely difficult".

Problem there - you could have the virus stored elsewhere on the computer. Many of those kinds of viruses will put themselves into start-up software as well; so running MBRFIX will remove it from the MBR yes, but then you'll re-infect the MBR on first boot.

And if you run MBRFIX from a machine that is infected - without booting from a CD first - then the virus will be in memory and just re-infect the MBR before you reboot.

So yes, it's not as simple as running MBRFIX - you actually have to disinfect the system too, which means eliminating any points where the infection may be - thus removing the battery on the motherboard to reset the BIOS, running the disk through an AV program on _another_ computer (or via a CD on the same computer), and fixing the MBR.

Re:Wow. Master Boot Record infectors. (1)

Mister Whirly (964219) | more than 3 years ago | (#34248016)

That is why I always keep a bootable CD with MBRfix and anti-malware utilities. UBCD4Win [ubcd4win.com] I would highly recommend. (I was assuming the booting from another OS and cleaning before doing the MBRFIX, but didn't expressly state that becasue, well, this is Slashdot and people already know to do this. I probably should have been clearer in my previous post on that.)

Have there actually been any MBR "bootkits" in the wild that have used flashable BIOS for storing copies? I always though that was a malware "urban legend". And shouldn't any flashable BIOS have some sort of jumper switch to prevent unauthorized flashing to being with?

Re:Wow. Master Boot Record infectors. (1)

TemporalBeing (803363) | more than 3 years ago | (#34249012)

Have there actually been any MBR "bootkits" in the wild that have used flashable BIOS for storing copies? I always though that was a malware "urban legend". And shouldn't any flashable BIOS have some sort of jumper switch to prevent unauthorized flashing to being with?

Yes there are, and the symptoms are hard to relate. It's things like the PS/2 mouse won't be detected, or the floppy drive won't work right. Had one on my desktop back in college - only virus I ever had. And yes, the only way to get rid of them. Variants of the Monkey [f-prot.com] virus do store themselves into the BIOS.

Re:Wow. Master Boot Record infectors. (1)

Applekid (993327) | more than 3 years ago | (#34247364)

FWIW, a user needs administrator access to run code that alters the MBR. As Raymond Chen puts it, it rather involved being on the other side of this airtight hatchway.

Re:Wow. Master Boot Record infectors. (1)

Amouth (879122) | more than 3 years ago | (#34246196)

actually i just cleaned an MBR infection off a windows XP laptop 2 weeks ago.

Re:Wow. Master Boot Record infectors. (1)

soupforare (542403) | more than 3 years ago | (#34246626)

I haven't seen it in a while but in the last few weeks here at the shop, there's been five or six machines with one. MbrFix [sysint.no] makes the job a little bit easier.

Re:Wow. Master Boot Record infectors. (2, Interesting)

HermMunster (972336) | more than 3 years ago | (#34246274)

It does more than infect the MBR. It creates a virtual file system and encrypts it's payload into that. This makes it undetectable by most antivirus software. Microsoft's Security Essentials DOES detect it, but it CAN'T remove it, at least as of a couple weeks ago when I first encountered the rootkit. You need to boot with your Windows CD (leaving most people that have a recovery partition in the cold) and fix the boot record.

windows.. (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#34245690)

Windows has always been known for its security, right?

Not for -your- security (2, Insightful)

Microlith (54737) | more than 3 years ago | (#34245736)

In recent versions of Windows, specifically Vista and Windows 7, Microsoft has introduced a number of new security features designed to prevent malicious code from running.

Of course, but the primary role of that lock down was to protect their DRM'd subsystems, which can be accessed by drivers running in kernel space, not to protect end-users from malicious driver code. Those were vicious but by far a minority, and hasn't improved the situation on Windows Vista x64 / Windows 7 in the slightest.

But hey, now Microsoft gets to bill everyone $250 for each driver release!

Re:Not for -your- security (2, Interesting)

K. S. Kyosuke (729550) | more than 3 years ago | (#34245816)

Of course, but the primary role of that lock down was to protect their DRM'd subsystems

In other words, the protection is there in order to prevent malicious code from stopping?

Re:Not for -your- security (1)

TemporalBeing (803363) | more than 3 years ago | (#34246398)

Of course, but the primary role of that lock down was to protect their DRM'd subsystems

In other words, the protection is there in order to prevent malicious code from stopping?

And turn over the keys to the RIAA and MPAA. Malicious AND Evil. Cthulhu would be pleased.

Re:Not for -your- security (3, Insightful)

clodney (778910) | more than 3 years ago | (#34246204)

In recent versions of Windows, specifically Vista and Windows 7, Microsoft has introduced a number of new security features designed to prevent malicious code from running.

Of course, but the primary role of that lock down was to protect their DRM'd subsystems, which can be accessed by drivers running in kernel space, not to protect end-users from malicious driver code.

Question for you - what benefit does Microsoft gain from enforcing DRM? They are not the copyright holders of music and movies, so they have no direct loss if pirating of content leads to reduced sales of music and movies.

Seems to me that if MS own self interest is considered they would put their effort into preventing piracy of their own software, and not worry about the DRM systems.

Windows Vista and 7 do indeed include DRM subsystems, but since I can't see how MS self interest is invovled in maintaining them, I think it is likely that these are things that the content holders demanded from them before they would grant MS the necessary licenses to produce players, or enter into partnerships to promote such content.

Either way, seems to me that MS is at most a reluctant partner in such schemes, and don't really care if DRM gets hacked. But driver signing and anti-malware do generate negative customer feedback, so I believe they take those things more seriously.

Re:Not for -your- security (1)

HermMunster (972336) | more than 3 years ago | (#34246650)

Licensing fees. That's significant income when you are talking about a billion or more potential installs.

Re:Not for -your- security (1)

BLKMGK (34057) | more than 3 years ago | (#34248664)

Since when do they get paid a licensing fee per install? Or are you saying there are a billion or so drivers? O_o

Re:Not for -your- security (1)

Stray7Xi (698337) | more than 3 years ago | (#34246770)

Question for you - what benefit does Microsoft gain from enforcing DRM?

They get to lock customers in. They convince media giants that their DRM is secure and should be used for all digital releases. So the media will say it works on Windows Vista/7 only.

Re:Not for -your- security (1)

nolife (233813) | more than 3 years ago | (#34246774)

You really don't know? With DRM, the media companies get on board because it provides a relative sense of security that their media is protected from unauthorized and uncontrolled use (through technical AND legal measures), win for them. Using MS DRM gets to lock you in to the MS suite of licensed proprietary codecs, software, and hardware. The more MS codecs, software, and hardware you are using, the harder it is for you to take your media to a non MS licensed software and/or hardware solution, win for them. The system is marketed as everyone wins with DRM! The flaw.. Although you are winning as well because you have limited access to the media, you are definitely winning a lot less then they are because of the DRM restrictions and the lock-in. Repeat the same reasons for Apple.

Re:Not for -your- security (1)

BLKMGK (34057) | more than 3 years ago | (#34248770)

I use x.264, no issues. I buy MP3 from Amazon - no issues. Heck even iTunes stuff isn't Microsoft although I don't buy that. What exactly have they locked me into on a 64bit Win7 platform that I cannot take elsewhere? All of the MSFT DRM stuff that's supposed to be around hasn't effected me so please, seriously, tell me what lock in has occurred? Signed drivers - okay yes I run those but much of my hardware has drivers on Linux too. Signed code, yup run that too although not all of what I run is signed - some of the OpenSource stuff I run isn't for instance and I have to click a box when it runs. So how have I been locked into anything exactly? Yes, MSFT markets their OS to media vendors and I guess they feel more secure but it sure does seem like all of the sky is falling crap hasn't panned out - I run ripped BD video with no issue for instance. Remember when everyone used to say the OS would halt if it saw that or would degrade it? Yeah... I called BullShit then too.

Re:Not for -your- security (1)

clodney (778910) | more than 3 years ago | (#34248796)

You really don't know? With DRM, the media companies get on board because it provides a relative sense of security that their media is protected from unauthorized and uncontrolled use (through technical AND legal measures), win for them. Using MS DRM gets to lock you in to the MS suite of licensed proprietary codecs, software, and hardware. The more MS codecs, software, and hardware you are using, the harder it is for you to take your media to a non MS licensed software and/or hardware solution, win for them. The system is marketed as everyone wins with DRM! The flaw.. Although you are winning as well because you have limited access to the media, you are definitely winning a lot less then they are because of the DRM restrictions and the lock-in. Repeat the same reasons for Apple.

Not buying it. Just about every media company is out there on iTunes, so the lockin apparently isn't very effective at keeping it MS exclusive. And if you mean lockin of the end user, I don't think that is happening either.

I use iTunes instead of WMP, but most everything I have purchased is in MP3 format instead of AAC, and WMA as a format seems all but dead. TVs and movies may still be format locked, but so many of those are ephemeral choices that I still don't see it as a big deal. And even there, MS doesn't really care if it gets cracked, since only a small fraction of people avail themselves of cracks.

Re:Not for -your- security (1)

HermMunster (972336) | more than 3 years ago | (#34249772)

Ummm, there's nothing to get. DRM has to be licensed. iTunes music is no longer DRM but they do encode to the file your credentials that anyone can look at.

As for videos, I'm not sure if they are DRM or not.

DRM by it's description is Digital Restrictions Management (btw, they changed the name to make it more palatable). So, to not buy what he's saying is to not understand the concept of DRM, nor in how Apple applies it selectively.

With Apple if they do DRM their videos you play them through Apple's tools such as iTunes or the QT player or on some Apple supplied hardware.

Re:Not for -your- security (1)

mcgrew (92797) | more than 3 years ago | (#34247002)

Question for you - what benefit does Microsoft gain from enforcing DRM?

  1. They get a signing fee for every movie, song, etc that hits the internet
  2. It's an attempt to cripple Linux

Re:Not for -your- security (0)

Anonymous Coward | more than 3 years ago | (#34247878)

Step 1: get the RIAA happy with your stuff

Step 2: get Congress to ban stuff the RIAA isn't happy with

Step 3: profit!

(Unintended Step 4: the world ends because of a particularly malicious rootkit)

Re:Not for -your- security (1)

BLKMGK (34057) | more than 3 years ago | (#34248680)

I'd appreciate some citation indicating that they collect a fee for every signed piece of media distributed. thanks!

Re:Not for -your- security (1)

BLKMGK (34057) | more than 3 years ago | (#34248648)

Yes that explains why it's on all of their released OS since implementation... Oh wait it's not! Sorry, if this were the case then 32bit would have it as well. I'm afraid I'm not persuaded. Much malware is in fact implemented via driver - things like keyboard sniffers etc. so yeah this does raise the bar although obviously not impossibly high and sadly not on 32bit yet either.

Infecting the MBR requires admin rights (3, Insightful)

gad_zuki! (70830) | more than 3 years ago | (#34245794)

or physical access. At that point anything goes. Why bother with screwing with code signing tricks when you can just run whatever code you like.

Re:Infecting the MBR requires admin rights (0)

Anonymous Coward | more than 3 years ago | (#34245922)

Code signing tricks allow you to infect the MBR, or did I RTFA wrong?

Re:Infecting the MBR requires admin rights (1)

Bios_Hakr (68586) | more than 3 years ago | (#34246338)

It's been a while since I played around with this, but I think that even "administrator" has problems installing unsigned drivers. You have to manually turn off some things on the command line and then reboot. On reboot, Windows will give a few error messages and then you can try to re-install the driver. On subsequent reboots, Windows warns you that things could be bad.

Re:Infecting the MBR requires admin rights (1)

gad_zuki! (70830) | more than 3 years ago | (#34246370)

Nope, I install an unsigned driver frequently for a project I'm working on. You just get a "ARE YOU SURE YOU WANT TO DO THIS" prompt/UAC event.

Re:Infecting the MBR requires admin rights (1)

Barlo_Mung_42 (411228) | more than 3 years ago | (#34248474)

You are both right. I think BiosHakr was talking about 64bit. 32bit Windows 7 systems just ask if you are sure but on 64bit you have to turn off signature verification or apply a test signature and turn on test signing.

Re:Infecting the MBR requires admin rights (2, Insightful)

BLKMGK (34057) | more than 3 years ago | (#34248810)

Nope, I don't think so. If you attempt to load up an unsigned driver on 64bit Win7 or Vista 64 and do not specifically go through the F key function to turn on the mode that disables signed drivers - at every single boot - you will get a nasty text message that HALTS the boot process, shows you the name of the unsigned driver, and shows you the registry key that called it (as I recall, been awhile).

Unsigned drivers on 64bit Windows are NOT the same as the unsigned code box you're talking about. Attempts to load unsigned drivers on the OS that requires it halts the boot process. You can go into a mode to load them - which I think even has visual indicators - or use a test cert - indicators here too I believe - but it's most certainly not the trivial thing to get aorund you've just described, sorry.

Doesn't actually bypass the code signing security (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34245812)

It lives in the mbr and sets a boot flag that lowers the load integrity threshold like users have been doing to run/test utilities that don't pay to get signed.
 

Re:Doesn't actually bypass the code signing securi (1)

h00manist (800926) | more than 3 years ago | (#34246760)

It lives in the mbr and sets a boot flag that lowers the load integrity threshold like users have been doing to run/test utilities that don't pay to get signed.

As long as they keep the cost and complexity of getting a signature so high this will always become a problem. Chinese drivers will publish without signatures, users will *want* to run unsigned code, and there goes your security scheme.

Re:Doesn't actually bypass the code signing securi (1)

sunderland56 (621843) | more than 3 years ago | (#34248670)

That mechanism was actually put there for driver developers - so that you can do the normal compile/debug cycle without having to sign each and every developer build.

This sounds like it makes things less secure - but in one way it actually makes things *more* secure. If every developer had the ability to securely sign code, it would be easy for one rogue developer to secretly sign nasty code and release it in the wild. If the signing key is only in the hands of one build engineer, and only lives on one machine in the corporation, there will be less correctly-signed-but-malicious modules out there.

(Of course, the mechanism was badly implemented - you should never be able to run unsigned modules on a consumer build of Windows. The bypass should only be possible in a developer Windows install, which is only available to registered developers).

Not a "New" Rootkit (5, Informative)

Avohir (889832) | more than 3 years ago | (#34245920)

This is a new version of a ~2 year old rootkit, also known as TDSS, and the company responsible for this particular parasite is a russian outfit known as Dogma Millions. Eset did a good writeup on the older version here [eset.com] . This newer version is actually even more interesting than the article indicates. It's intelligent enough to send tools like MBRCheck off to look at a backup of the MBR so that they'll erroneously return a "clean" verdict while the system remains infected. The best bet for removal is TDSSKiller [kaspersky.com] by Kaspersky (the company that wrote the blog entry).

Re:Not a "New" Rootkit (1)

iMouse (963104) | more than 3 years ago | (#34246358)

TDSSKiller sometimes damages the MBR upon removal, causing a BSoD in normal mode, but not in safe mode (yeah, I thought it was strange too).

For systems that BSoD after removal of rootkit.Win32.TDSS.tdl4 with TDSSKiller , rewrite the MBR with TestDisk, then insert a Windows Vista or Windows 7 disc and run the startup fix. This will resolve the BSoD issue and properly repair the MBR. Be very careful with TestDisk as you can really screw up your disk's partitioning by selecting the wrong options.

2 out of the last 5 systems I cleaned had this issue. It appears to possibly be a conflict between something TDSSKiller is doing and Dell computers that contain a MediaDirect partition.

Re:Not a "New" Rootkit (2, Interesting)

Ziekheid (1427027) | more than 3 years ago | (#34246970)

I have a box infected with this and thought I had removed it. After running the utility you linked I found out its mbr is still infected though, so thanks for the link, but it's not able to 'cure' the infection.
Some solutions on the Kaspersky forum suggest rewriting the MBR which I will attempt now.

I traced the initial infection back to a vulnerable Flash installation which locks certain flash files so they can not be updated anymore after infection keeping you vulnerable for future infections.

Re:Not a "New" Rootkit (2, Informative)

iMouse (963104) | more than 3 years ago | (#34247178)

The MBR isn't the only point of infection. TDSS also patches legitimate system files, resulting in reinfection of the MBR if the infected files on the drive are not taken care of first.

Re:Not a "New" Rootkit (0)

Anonymous Coward | more than 3 years ago | (#34247506)

Those were cleared on the second it happened. There was a svchost process running from the user dir at that time and it was killed and removed.
I do wonder though.. a proper rootkit shouldn't have made it possible for me to view the malicious process in the first place..

BitLocker time? (1)

mlts (1038732) | more than 3 years ago | (#34246182)

TPMs can be used for nasty things, but this is one of the good things about BitLocker and TPMs -- a modified MBR would result in the machine not booting because the TPM would not hand the key over to the encrypted system partition due to the changed code.

Of course, the TPM would have to be "sealed" before the malware hit the system, and a viral infection is not the first thing on the list to check if a box is sitting there in recovery mode asking for a key or a USB flash drive to continue booting.

To me, if one has Windows 7, an edition that supports BitLocker, and a TPM/support for it in hardware, it becomes a no brainer to enable BitLocker if only to have protection against "evil maid" attacks, as well as MBR infections.

Re:BitLocker time? (1)

necrogram (675897) | more than 3 years ago | (#34246672)

Amen. Thats one of the things i'm working on is getting my os imaging process to enable bitlocker without human intervention.

Of course, that old BIOS option where it would protect the MBR worked real well.

The driver signing is mainly for DRM (1)

Myria (562655) | more than 3 years ago | (#34248166)

Vista and 7's driver signing requirement is mainly for DRM purposes. The main thing Microsoft wanted to stop with driver signing is device drivers that create fake sound cards and video cards that can capture decrypted DRM-protected songs and movies. It doesn't help much with rootkits. This is why if you disable driver signing yourself, Vista and 7 will refuse to play some types of DRM-protected media. For example, some Blu-Ray players.

Rootkits can just attack the boot process to disable the signature checks, as shown here. But there is another way - third party companies don't have the stringent secure coding standards of modern Microsoft, so all you need to do is find a bug in a legitimately signed driver, and you're in. I found a signed Win64 driver that adds IOCTLs to let Administrators set CPU MSRs - you can exploit that by having it set the system call handler address to your own memory, and you're in.

I like how Windows warns you about unsigned device drivers installed the normal way - this is good for users, and helps keep hardware companies in check a little bit. However, removing the right to load unsigned code without disabling part of the OS is unfair.

Re:The driver signing is mainly for DRM (1)

Animats (122034) | more than 3 years ago | (#34248400)

Vista and 7's driver signing requirement is mainly for DRM purposes.

No, the driver signing requirement is for quality control purposes. 60% of Windows crashes used to be driver-related. Now, Microsoft actually requires a proof of correctness, using their Static Driver Verifier [microsoft.com] , before a driver is signed. The prover tries to determine that the driver can't call a driver API wrong and is free of pointer errors. The goal is to eliminate damage to the rest of the kernel, not check whether the device itself will work. The prover is quite good - 97% of the time it either reaches a successful termination or reports a counterexample - a test case that will break the driver. 3% of the time, the analysis takes too long, the prover gives up, and the code has to be simplified or cleaned up.

Re:The driver signing is mainly for DRM (2, Informative)

Myria (562655) | more than 3 years ago | (#34248488)

Vista and 7's driver signing requirement is mainly for DRM purposes.

No, the driver signing requirement is for quality control purposes. 60% of Windows crashes used to be driver-related. Now, Microsoft actually requires a proof of correctness, using their Static Driver Verifier [microsoft.com] , before a driver is signed.

You're talking about the Windows Hardware Quality Labs [wikipedia.org] signature, not the kernel-mode driver signing [microsoft.com] requirement in 64-bit Vista and 7. A WHQL signature is not required in order to have a driver load, a kernel-mode driver signature is. Microsoft only does their quality testing with drivers submitted to WHQL; an appropriate VeriSign certificate is enough to get the driver to load, without any quality checking on the part of Microsoft.

It is the kernel-mode driver signing requirement that this rootkit bypasses, not the WHQL signature.

Improve Windows version detection... (1)

nuckfuts (690967) | more than 3 years ago | (#34248792)

FTA:

Alureon patches the Windows Boot Configuration Data to make the machine think that what's loading is Windows PE, rather than a normal version of Windows, which prevents code integrity checks from being performed.

If this rootkit is just flipping a few bits to spoof the Windows version, surely Microsoft can implement a more sophisticated way of checking what version of Windows is booting up.

MBR Protecttion (1)

nuckfuts (690967) | more than 3 years ago | (#34249008)

TDSS ... is an example of a particularly pernicious type of rootkit that infects the master boot record of a PC.

I've seen some BIOS versions that can write-protect the MBR. Perhaps this should be more widely used. I can verify that these TDSS rootkits are a bitch to remove.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...