Tool makes mincemeat of Windows passwords A security researcher has released an easy-to-use tool that accesses locked Windows computers in seconds without entering a password. The tool, which was released Tuesday by Adam Boileau, works by connecting a Linux machine to the Firewire port of the target PC and modifying the password protection that's stored in local memory …
"After all, how hard could it be disable Firewire connections while a PC is locked?"
Microsoft cannot win this one. If lock my workstation while I am capturing video via 1394 or copying files to a firewire drive, I would be quite unhappy to find that locking my workstation disabled the 1394 ports.
On the other hand, they cannot leave this unpatched. Too many people rely on hardware locks and the ability to lock the workstation.
Why not fix the direct memory problem? Why should a 1394 device (or any device plugged into an external port) have absolute access to anything as vital as memory, hard drives or such just by the merit of being plugged in?
(Yes, before you ask, I do disable autorun and autoplay on all of my machines. Keeps those pesky iPod virii off my Windows machines.)
It is nice to see that the 1394 spec is an equal opportunity offender, hitting Linux (what about BSD?) and OS X, too.
You don't need to disable existing firewire connections while the machine is locked, just prevent new connections from being made. I know nothing about how firewire works, but I assume a new connection raises some kind of 'event' which can be ignored.
OK, it's a NEW exploit for cracking a Windows password, but far from the first.
All you need is a CD or USB disk and BartPE + Sala Password Renew, or pnordahl's Linux-based password resetter to crack any NT-based Windows machine (including Vista). And with physical access to a DC, no problem with resetting the Domain Admin pword either.
This is a yet another symptom of functionality creep.
Most laptops have connections that we never use... but we keep them enabled just in case...
So time ago I bios-disabled all connectors I never use: COMs LPTS, Modems... etc.... and not only this increases security (by simply applying the "reduce the attack surface" principle) but it actually it can increase performance by precluding drivers from loading...
The problem arises in hardware - basically, firewire is designed such that DMA is permitted without the intervention (or even consent) of the OS. One of the advantages is that you can obtain a core-dump of a crashed paniced kernel via firewire.
What isn't clear is how to really mitigate the threat.
Incidentally, I disagree with the "if you have physical access to the machine, all bets are off" argument, because this usually requires a reboot to a liveCD, removing the disk, or attaching a probe to the PCI bus. Most such attacks (except extremely sophisticated forensics) will cause the PC to be rebooted, thereby losing encryption keys.
So reading the article I've come to the same conclusion that this is nothing to do with the OS as such. Sure Windows or any other OS could disable Firewire DMA but then no devices would work. The suggestion of not allowing new connections is a bit of a red herring because this is not at the OS level it's harware. If the owner of a machine has enabled (or rather not disabled) Firewire then they are at risk.
This means that the best you could hope for is that Microsoft release a patch that disables Firewire by default and the user has to actively enable Firewire when they need it. If the device is removed then the OS must disable Firewire DMA and the user must enable it again when connecting the next device.
How long before people post complaints of Microsoft has for some reason made using Firewire difficult.
For many years periferal chips have had a high speed mode where they dump data stright into RAM bypassing the CPU. This usually occures during CPU wait states where they can control the address and data buses. However I would have thought that it would only have access to a limited area of RAM devoted to the DMA process but I don't know.
I expect the technique of accessing an internal area of a 'computer' that has been unencrypted will work on everything including Chip 'n' Pin machines. I would say this needs a hardware solution. Perhaps we need an encrypted CPU, one who's instructions are actually carried out encrypted so it's impossible to tell what it's doing until it's done. This may be logically impossible, I can't get my head round it.
If the 1394 is disabled in BIOS surely the attack must fail?
This is down to best practice of disabling services you don't need and I wonder how many of those at the greatest risk from this attack, perhaps in large buildings with lots of offices where physically security could be tricky, know that 1394 exists let alone actually using it?
to single out MS on this one.
I'm a Linux advocate and I can't believe I'm saying this, but if Apple and the Linux kernel team haven't sorted this out either, then why pick on MS?
Maybe this could be an opportunity for MS to prove to the world it has changed (as they are so keen on telling us) by solving the problem first and share the solution with everyone else ;) Oh, is that a pig I see going past my 2nd floor window....?
@Nick Askew
The underlying vulnerability is nothing to do with windows. The hack that is exploiting it is, however, targetted at windows.
@Wayland Sothcott
There's no reason why you couldn't put a hardware encrypt/decrypt between the CPU & the memory (although it would obviously slow the system down quite considerably) - and it would be possible to flag "sections" of memory as either encrypted or unencrypted. This would allow you to (for example) still use DMA to unencrypted memory, and then either continue to use it unencrypted or take the hit of encrypting it. The problem (in making this secure rather than just LOOKING secure) would be getting the chipset to use the encrypt/decrypt for CPU access, and not non-CPU DMA. I don't think it's insoluble, but it's beyond my knowledge thank god - I've got enough problems dealing with OS level encryption to stop people losing sensitive data the old fashioned way.
"Microsoft is sure to point out that it's made possible by features built into the IEEE 1394 specification. That's true, but we're not sure that's enough to get Microsoft off the hook for failing to fix a weakness that's been in the public domain for at least two years."
Well the sure are to point out that it's the spec.
just like the guys coding Linux are sure to point out it's in the spec...
the question is who breaks the spec first?
do MS break the spec, fix the hole and then get critisism for not following a standard spec, or will the Linux guys do it first, leaving microsoft getting critisised for leaving the hole open...
after reading the article, I was somewhat surprised the author didn't refer to MS as M$, micro$ucks, micro$haft or any of the other innane I just don't like microsoft nicknames applied by his ilk
long and the short, it's not a nice bug, but it's also not microsofts fault. -if anything that researcher finding it affected all systems should have taken his beef up with the engineering council who wrote the specs.
Is not firewire, the firewire protocol or any 'bug' in firewire.
The real issue is that windows uses well publicised <i>physical</i> memory addresses for various parts of the OS and this is bad.
Having direct access to physical memory is not as useful as it first seems, since all modern operating systems use virtual memory, and any virtual memory block could be read/written into just about any physical memory locations, which makes it very difficult to predict what is where in physical memory at any time, except of course for Windows', linux's and Max OS X's placing of some sensitive parts of the OS into known and publicised physical memory locations.
The real solution is for the OSes, if really necesary to have these things at a fixed physical location, to dynamically allocate that location at boot time and prebind executable as they are loaded. Rather than hard coding it into the libraries.
I must admit that I am years behind the times, but when I studied DMA controllers in detail, the OS programmed the memory mapping registers on most architectures to limit the DMA controllers access to just the memory that it needed. This was before the advent of busmastering controllers, but I cannot see that not limiting the memory region, or allowing the controller to access the memory management registers can ever have been a good idea.
In the normal scheme of things, the DMA write operations needs the controller to know where it is safe to write the information, even if it is taking control of the bus in a non-solicited manner. Of course, read operations are not as critical, but again, for a DMA controller to do anything useful, it is necessary for it to be told where to look.
As a result, allowing the controller carte-blanche to the memory map of the system should never really be necessary. Surely this means that the DMA access for firewire must be a mis-feature at the very least, even if it is not a flaw in the design. Or is it really a problem with the northbridge memory controller in a PC?
Maybe someone can enlighten me about why you would want to be able to allow a DMA controller full access to the memory, except to allow a box to be owned in this manner.
BTW, this is also an old story. Apparantly the technique was presented at Ruxcon in 2006.
as the article says, it is a fault of the firewire specification, if an OS maker tried to work around the flaw theyed only be hammered by the users for not sticking to the specification
as most of us have no need what so ever for firewire there is a nice physical security device for dealing with unneeded ports - its called 2 part epoxy resin - theres no way any kind of software attack id getting thru that!
as firirewire on laptops, i believe sony started the craze when the called it i-link and used it on their cybershot cameras in the days before usb2, now theres very little point to it (tho in those early days it was dubious as to exactly what your average celeron 500 / 128mb ram / win98 laptop could make of a high speed firewire connection...)
Useful comment, but not completly valid. The OS always has to be able to find this information, so has pointers that can themselves be found (paging tables with known base addresses etc.) All you have done is added an extra level of abstraction, which may deter some people, but not those with serious knowledge, or access to clever tools. Of course, this may make OS's with their source code visible more vulnerable.
This has been possible on Windows Vista and XP for quite some time using a simple CD. You insert the CD in the drive at boot time and select the windows account you want to erase the password to, it just erases the password so after a reboot you can login with the account and no password.
I have verified this on both a Vista Home and XP Pro installation and both worked flawlessly.
http://home.eunet.no/~pnordahl/ntpasswd/
If the problem is in the spec then...
Firewire originated with Apple, so it's their fault.
@AC "now theres very little point to it"
Firewire is a great interconnect, my Maxstor external disk ran quite a bit fast connected to Firewire than it did with USB2, even though the peak theoretical bandwidth was only 400Mbs against USB2's 480Mbps. But the best thing about Firewire is that it doesn't need a computer at all. I can plug my video camera straight into my PVR and copy stuff over, or write it straight to DVD without having to faf about loading all sorts of shit on my PC. Adobe Premier is a fantastic bit of software, but if all I want to do is stick a short bit of video onto a DVD for friends it's not exactly the most socialable way to get it there.
But I can not for the life of me see why an external peripheral should be able to set up it's own DMAs. The normal scheme of things is that a peripheral interrupts the CPU and the CPU then sets up the DMA and is notified on completion.
Peter G wrote:
"The OS always has to be able to find this information, so has pointers that can themselves be found (paging tables with known base addresses etc.) "
I think what Kenny M was noting is that the pointers point to:
the_same_place_for_all_instances_per_OS_every_session;
whereas, is it not feasible to write kernel code for these pointers to point to:
someplace_(pseudorandomly)determined_at_boot_time?
This - IMHO - is not "an extra level of abstraction", rather it is a measure of obfuscation that is applied per instance, per session.
The kernel code could still be published, open source being lovely and all that, and the combinatorial limitation of the chosen implementation of "(pseudorandomly)" could even be explicitly stated in comments for those to busy or lazy to independently derive it. The <bold> point </bold> being that the range of possibilities generated (pseudorandomly) being just sufficiently high enough to deter the determined yet time-limited exploiter ("you've got three minutes left before the user returns to his desk, Ethan Hawke") from attempting this escapade.
However, for the majority of people with Firewire connectors on their machines, I recommend a small does of two part epoxy adhesive (e.g. "Araldite") as opposed to "super glue", such a cyanoacrylate adhesive may not set
I was thinking the same thing, what's Maynard and crew been up to now!
Great news, at least I have another excuse to the Missus about justifying that expense on buying my EEE PC and taking everywhere I go. "Sorry my dear! You just never know when some poor soul may need saving from a locked Windows PC!".
This has been possible on Windows Vista and XP for quite some time using a simple CD. You insert the CD ....
yeah but this exploit will get you into somebody elses logon, without having to reset anything, so they wont know. quickly.
I thought firewire was dead now anyway? , and why not clear things like passwords out of the ram when the machine is locked?
So basically, it seems in this case that installing a Firewire port is equivalent to installing an externally readable (writable?) memory probe. And then somehow blaming MS/Apple for it... Hmm, yes Apple...
Software clearly isn't the culprit here, neither are drivers. This is a hardware glitch (aka feature).
No, the fault lies with the designers of Firewire. There is no justification for allowing a Firewire device to probe memory beyond the range given to it by the OS (possibly for debugging, but then it should default to off). All other DMA devices must be told by the OS where to transfer data to.
This is such poor design that I wouldn't be surprised if some fraction of Firewire ports already do not adhere to the spec (and are not vulnerable).
The point is, once you're in with a login without a password, what do you look at? If you go into a locked PC you've got everything open that's being worked on, etc.
@Kenny Millar
This is completely unworkable. Even if you did abstract the base addresses of important OS stuff, you would still have to store the addresses of the base address lookup table (or however you did it) somewhere. For systems programming, and low level work it would make coding a nightmare.
From http://www.matasano.com/log/695/windows-remote-memory-access-though-firewire/:
[quote]The reason Maximillian’s attack doesn’t seem to work against Windows XP is that OHCI specifies “Asynchronous Filter” and “Physical Filter” CSRs (a CSR is a hardware ioctl, by the way); if these CSRs are set to zero, the FireWire chipset will reject requests to access host physical memory. According to the spec, they default to zero. Windows doesn’t set them. So, by default, Windows disallows FireWire DMA.[/quote]
DMA on a hot-pluggable interface is a problem.
why should external hardware have unfettered access to my system's internals? bigger machines have had things called IOMMUs for a while that stop, a bit like the MMU on your CPU, hardware from looking at memory they shouldn't. crypto is another way to do this, it's much less efficient though.
I very much hope that all those condemning firewire for its fundamental design will also slag off the existence of the PCI bus and all those other completely standard features of PC architecture, because it's exactly the same.
Yes, Lou Gosselin, it is exactly like "installing an externally readable memory probe". So is plugging in a PCI card. So is plugging in a PCMCIA card. So is plugging in a CPU, or a RAM chip. No, Wayland Sothcott, it's been many many years now since DMA was limited to accessing the areas of memory that the CPU maps for it. Since the invention of the PCI bus, basically.
It's one of those things that is implicit but perhaps never made quite as clear as it should be: the firewire port is exactly like having a PCI expansion slot on your front panel or a PCMCIA slot in the side of your laptop; anything you could do by one you could do by the other. It's no more a "design fault" that it provides full access to the system busses than any of those other interfaces. The rule is still exactly the same in all cases: if you let someone plug hardware into your PC, they can control it. Doesn't matter whether it's USB (did I mention it's trivial to own a machine through the usb port?), Firewire, PCMCIA, PCI, or even the serial port; it's all the same. About the only thing that's not vulnerable to an attacker with physical control is the power connecter.
Yes, Lou Gosselin, it is exactly like "installing an externally readable memory probe". So is plugging in a PCI card.
Obviously PCI cards have access to the bus, this should not surprise or disappoint anyone. DMA is not intrinsically faulty. Sound cards use dma, so do network cards. Nobody expects these to be vulnerable. These devices are given memory addresses by the CPU and NOT the external cable. The problem is that apparently the Firewire architecture is designed to allowing Firewire nodes to make memory requests directly by exposing DMA to the outside. This design has significant ramifications to security beyond PCI bus sniffers.
So the comparison between Firewire (an external bus) to PCI (an internal bus) is not really fair. As for USB, it doesn't work like Firewire does. Devices do not instruct the USB host controller as to where to read/write memory. DMA is used as intended and the range is determined by the OS, not the device. You may have a valid point with PCMCIA on Laptops, although that's a different story.
Even if it is possible to disable the flaw in software, some Firewire devices will cease to function any longer because this is how they work by design. The article itself said that certain device profiles will open up the hole.
That being said, it is very likely that many USB (and Firewire) drivers have buffer overflow bugs which could be exploited without this design flaw. Unlike the flaw, these would have to be OS specific and could be fixed once discovered.
APPLE ! they invented the bloody thing in the first place..
Now that the flaming is over
I am a heavy user of firewire (in windows) . It beats the snot out of usb anytime.
I have external harddisks on firewire , my High Def (1080i) camcorder uses firewire, i even have 2 DVD burners on firwire. No drivers needed. Plug it in and it works.
For a time (when gigabit lan didn't exist or was outrageously expensive ; 5 years ago ... ) i even had 4 (windows) computers interconnected with firewire ( you can run tcp/ip over firewire you know ? 400 Mb / s instead of 100 Mb /s ...
Big improvement !
And with ieee1394b you can go 3 Gb/s and beyond !
We should have listened to Von Neumann.
Von Neumann wanted to partition system memory, but we adopted a model of general purpose shared memory as a matter of efficiency and flexibility.
The Von Neumann machine, as proposed, would have been immune to code insertion exploits: buffer overruns would only have affected data memory, not code memory.
Had we been using a Von Neumann architecture, I am pretty confident that as networking and peripheral use grew, we would have expanded the model and developed memory sandboxes for things like DMA and this exploit would never have existed.
We could still do it today!
Pah! HARVARD partitioned data side from program side.
"Harvard architecture is a computer architecture with physically separate storage and signal pathways for instructions and data. The term originated from the Harvard Mark I relay-based computer, which stored instructions on punched tape (24 bits wide) and data in electro-mechanical counters (23 digits wide). These early machines had limited data storage, entirely contained within the data processing unit, and provided no access to the instruction storage as data, making loading and modifying programs an entirely offline process."
"The von Neumann architecture is a computer design model that uses a processing unit and a single separate storage structure to hold both instructions and data."
Harvard architecture processors are available, e.g. SHARC - they are somewhat optimised for hard-real-time numerical calculations (e.g. SONAR and RADAR signal processing) rather than general purpose computing. There is no port of Vista to a Harvard processor in the offing AFAIK.
Actually, it would take several devices; one for each different size port connector. But all it really consists of is a plug which locks into the port and cannot be removed without a physical key, or obvious physical damage to the computer.
This won't help if someone routinely walks away with firewire devices plugged in, but an unused port could be secured.
Title chosen to make it obvious that this is a patentable concept, and I claim first publication rights. No other patent filers need apply.
You know what is the really bad thing ? ALL intel processors are HARVARD machines by design !. it's that concoction that IBM called 'PC' that did a lot of kludging to get around the 'harvard' architecture.
The annoying part with harvard is you have to split your memory up front. this much for code, that much for data. and dynamically loading a program becomes difficult... especially with modern systems that can remap ...
I too like harvard machines , especially for embedded applications that are mission criticla. There is NO possibility for a runaway progrma to corrupt its own code. Also the I/O space is separate on a good harvard machine.
That , and it makes debugging code easier. if you look at a hexdump you know what you are looking at this is code , that is data , that is i/o.
So Frank's comment implies this situation is securable on all platforms? Surprised at least one of them hasn't done it by now than.
All you need to retrieve passwords etc. from a laptop is firewire connected to a linux (prolly, any) system... at least some iPods can run linux and have firewire ports... this would beat the hell out of that boot disc memory reading attack for getting hdd encryption keys out of a locked laptop. Someone leaves the room, you connect up your iPod to the lapop, unplug it from the mains, and scarper with it while it's busy getting all the passwords. Well before the battery runs dead you'll have all you need.
And note that changing the password with a boot CD a) wouldn't give you hdd encryption password, and b) would invalidate any autocomplete password entries someone's got in IE (not sure about FF, but I bet you could get whatever you needed to bypass its encryption also) which makes it easier and faster to exploit anything this guy has access to.
If you can take a dump of the entire memory, then time is not a problem for mining data. Of course you would not be able to break in to the machine in a hurry, but that is only one possibillity.
And I believe that my point still stands. If the Kernel can find the information, then so can another tool specifically written to follow the same evidence trail. Once you know the rules, you can code a analytical tool to apply them. All you need is a device like an EeePC (but with a firewire port) with tools intelligent enough to recognise the OS in question, and apply the relevent rules. A serious hacker will have a toolkit with the rules built in ready and waiting. In in seconds.
My guess is that those people who think it is too hard have never delved under the covers in a real OS to understand how they work. And I know I am being a pedant, but I do not see the difference in this context between 'abstraction' and 'obsfrucation'.
@alphaxion
OS X is *not* based on the BSD microkernel. Everyone needs to get their facts right on this as they keep positng the same old rubbish again and again. OS X is based on a custom microkernel which is closely based upon the MACH micro kernel. The only thing in OS X related to BSD is a complete BSD subsystem layer (all the little BSD utilities and libraries.)
To quote Apple on this:
"This fully-conformant UNIX operating system—built on Mach 3.0 and FreeBSD 5—bundles over a hundred of the most popular Open Source products. You can shell out with bash, tcsh, ksh, and zsh; edit your code with emacs, vim, and nano; and build your projects using gcc, make, and autoconf.
Need something a little higher-level? Run your X11 apps side-by-side with native apps using X11R7 from X.org. Serve your web site with Apache 2.0 and PHP 5. Start scripting with Ruby and Python, and build web applications with the included Ruby on Rails framework. You can even measure your application's performance using DTrace from OpenSolaris."
@- Everybody who declares that physical security is the solution.
Imagine a call center envrionment. Hundreds of reps, each with the (theoretical) ability to COMMIT MASSIVE FRAUD.
Late at night, during the slow times, only two people are on-shift on a given team (or more, but all except one are party to the deal) The patsy gets up, locks his/her computer, and goes to the bathroom. Perp reaches over, unlocks patsy's workstation, and makes several thousand dollars in 'innapriate adjustments' before locking the workstation again.
Physical security is nice, but trusting people means having a valid audit trail.
OK, since everybody and their dog is saying this vulnerability is inherent in the 1394 spec, would someone please point me to the part that requires all of a computer's physical memory to be accessible via firewire?
Yes, 1394 specifies a "memory-like" model for (non-isochronous) transactions between nodes, but I don't recall anything that requires any particular mapping between this abstraction and the machine's RAM. This looks to me more like an implementation defect (though perhaps a widespread one).
I could be wrong though, and if so, I'm perfectly ready to be set straight.
Call to all fanboys!
Our leader needs us in the fight against the FOSS "evil-doers".
Mail this letter to your representative to help our leader win the struggle!
Glorious victory will be ours!
To
Mr. Jainder Singh, IAS
Secretary
Department of IT
Ministry of Communications & IT,
Electronics Niketan
CGO Complex
New Delhi - 110 003
Respected Sir
Please write a paragraph about your organization
Please paraphrase "We support OXML as a standard that encourages multiplicity of choice and interoperability giving us the ultimate consumer the choice. * recognizes that multiple standards are good for the economy and also for technical innovation and progress in the country, especially for smaller organizations like us, who require choice and innovation"
Please write about your work
Please paraphrase "*** also supports OXML as this does not have any financial implications thus releasing our resources for welfare and development of society."
Thanking You
Yours Faithfully
Name Designation
wiki.linux-delhi.org/cgi-bin/twiki/view/OpenStandards/MsNgoLobby
Trix wrote:
"All you need is a CD or USB disk and BartPE + Sala Password Renew"
Jason Croghan:
"You insert the CD in the drive at boot time "
Both these methods assume that you can boot of a CD/USB and that it hasn't been disabled in a password-locked BIOS.
Yes, I know that you can reset the BIOS but that requires a screwdriver and a little bit of technical skill. And it might be tricky to get to on a laptop.
Well Jackie its a good job our new ID card scheme will not be intra/internet accessible. So I guess it will be stored on emm PC's? So now I can focus on how the F### we stop leaks from millions of government pc's
Suggest we sub contract to Phorm..they know how to collect data
Yours obediently
ps application for salary increase enclosed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
