Microsoft Master File Table bug exploited to BSOD Windows 7, 8.1 Until Microsoft patches this problem, use Chrome: a slip in file-path handling allows attacker to crash Windows 7 and Windows 8.1 with a file call. The bug's triggered if Windows' Master File Table is included in a directory path – for example, if the attacker included $MFT as a link to an image in a Website. “Anatolymik” of …
In Microsoft world, browser and is are very tightly integrated, it's not surprise you can't uninstall internet explorer or edge.
In other news, another huge Windows defender exploit discovered that allows anyone to remotely run stuff on your machine.
I really don't know why people that don't need to run Windows, still run Windows....
"I really don't know why people that don't need to run Windows, still run Windows..."
I do - and, I suspect, so do you.
It's because a huge number of "people that don't need to run Windows" are mostly just ordinary people, who simply buy their computers off the shelves in places like PC World, Argos, or wherever, and just use it with whatever it comes with.
"I do - and, I suspect, so do you." - I have banished Bloat from all web facing boxes. They all run Linux (Mint on some and Manjaro on others). If possible all new kit will never have Bloat or it will be replaced ASAP.
The real problem for most people, they buy what is readily available which is Bloat, ChromeOS, or MacOS. The low price (aka cheap) will be Bloat or ChromeOS.
Naah... that thing about the browser and OS being so tightly integrated that it can't be removed was just a story.
MS gave the Windows Explorer in Win 98 the same interface as Internet Explorer so that they could try to sell the idea that they were the same thing (so why use Netscape when you're already using Explorer for all of your file management needs?). There was never a reason for the total integration beyond running Netscape out of business... which they did.
MS successfully sold this lie to the US government, gullible as they were, that IE was so tightly integrated that it could not be removed without breaking the entire thing. Of course, they never mentioned that some guy out there on the internet had already created "Mozilla's Revenge" that forcefully uninstalled IE from 98, replacing it with explorer.exe from 95 OSR2 (which the user had to supply). XPLite did the same for Windows XP.
We're supposed to believe that the mighty Microsoft, the creator of Windows, the people with the source code, the ones who embedded IE into Windows in the first place (95 didn't have embedded IE) could not remove IE, but two nobodies from somewhere out there in net land were able to accomplish it?
I never ran XPLite (it was a long time ago, but I remember wanting to be able to approve the updates one at a time, which required IE in XP), but I did use Mozilla's Revenge in the 98 days, and I had no problems running an IE-free Windows. Nor do I now with 8.1, or with 7 before that. "Not officially uninstallable" doesn't mean you can't get rid of it... it just means MS won't make it easy.
When I was testing 10, it also ran fine with Edge, Cortana, Windows Store, and all other unwanted junk forcefully removed. I never got around to removing IE; I figured I would go one better and remove 10.
Careful what you wish for, AC. If you got your wish and everyone gave up Windows, all of those black hats that are currently busy ignoring Linux (in desktop form) would find it an increasingly worthwhile target. If you think there is something magical about Linux that makes it more secure than Windows, I think you're going to be disappointed... if it had as many people trying to crack it as Windows does, a lot of undiscovered (and largely irrelevant, due to Linux's 2% share of desktops) exploits would suddenly move into the "discovered" column, I think. Of course, the Linux devs would patch it the same day and that would be that (instead of having to wait up to a month for patch Tuesday, or more if MS decided to sit on it). It's a problem I would love to have (I use Linux Mint 18.1 dual booted with 8.1), since it would mean that Linux has finally become a viable alternative for more than a small handful of people.
> all of those black hats that are currently busy ignoring Linux (in desktop form) would find it an increasingly worthwhile target.
There are actually more Linux servers on the internet than Windows servers and yet it is the Windows servers that are being attacked more often.
There are more difficulties to attacking Linux than you imagine. First of all Windows is almost a monoculture with only a small number of variations. Linux has dozens of variations, each recompilation by the distro builders can move the potential attack surface.. This means that if a vulnerability exists there may have to be many variations of the exploit code, each only working with a subset of the systems.
Second there are much fewer 'convenience' features in Linux. Windows has designed in mechanisms intended to make it easier for users that make it _much_ easier for black hats. Many of these have been disabled or been notified with a dialog box, but not all of them. For example downloaded files can be executable with no further action; inserting USBs, CDs and DVDs could execute code automatically; clicking on an email, even if selecting it for deletion, could cause an application (such as Office) to open an attachment and execute macros or code inside; network ports used to be (and may still be) left open by default; on boot the network starts before the firewall has been loaded giving a small window of opportunity.
Linux doesn't do any of those.
Linux servers and Linux on the desktop are completely different when it comes to attack vectors. I am well aware of the number of Linux servers out there across the internet... those are internet-facing installations by design and necessity, and they're administered by people who hopefully know how to secure a server.
Desktops, though, are what we were talking about, and I did mention that I was talking about desktops. Desktop malware tends to be about numbers... they want to get as many people in the botnet (or the ransomware attack, or whatever) as possible. Hardened targets like professionally-managed web servers are not good candidates for these kinds of attacks. A determined foe working against one machine may be able to compromise it, but that's not what we were talking about. The kinds of bad actors in this kind of attack are not targeting a specific PC or server... they're looking for large numbers of machines that can be compromised quickly and automatically. They're looking for systems that are unpatched, run by people who can be fooled by social engineering.
The most common malware vector for that kind of attack is people being tricked to run the malware. Now, admittedly, Windows users are much more likely to be running with full privs for everyday browsing than Linux users, but that's also one of the things that non-tech users don't like about Linux. They want it to be easy to do things that might be dangerous, because they dislike inconvenience more than they understand or care about the risks.
Web servers have a smaller attack surface than desktops, but a Linux distro that's going to start making inroads into Windows' market share is going to need a lot of the same conveniences people have on Windows. A modern distro has a browser, a windowing environment, an X server setup, all the same device drivers as in Windows, a media player... all kinds of stuff. Right now, there's just about no desktop Linux malware, as 98% of desktop systems would be immune to it. Why even bother? That's too small a percentage to self-propagate... that's into herd immunity territory. But if it started to rival Windows, it would begin to look like a target.
It's still a problem I'd like to have.
Umm, not so fast ..
There are more difficulties to attacking Linux than you imagine. First of all Windows is almost a monoculture with only a small number of variations. Linux has dozens of variations, each recompilation by the distro builders can move the potential attack surface.. This means that if a vulnerability exists there may have to be many variations of the exploit code, each only working with a subset of the systems.
I am completely onboard with an argument that almost anything but Microsoft code is far less work to keep safe, but I disagree with your assertion that recompilation shifts the attack surface in a meaningful way (although, to be fair, you used the word may :) ).
Two cases in point:
- The Heartbleed OpenSSL problem buggered up pretty much any Linux distro because recompilation did not address the fundamental problem hiding in the code.
- The "Shellshock" bug even reached beyond Linux and also caused risk to macos platforms as well.
That is, of course, just two issues against a veritable avalanche of problems on Windows in the same span of time, but they should serve to protect you from a misplaced feeling of security: you still have to work for it.
You just have more time for beer in between :)
As I recall, Microsoft lost that court battle and was to be split into 3 businesses. Microsoft appealed and then G.W. Bush took over as President of the United States, installed new people in the DOJ, he instructed them to stop the current appeal and settle with Microsoft. Microsoft got away with a slap on the wrist again.
It was a bad time for the tech industry as things like CORBA, JavaScript, Java and other technologies were gaining with traction from Netscape as the browser company and web server business. The industry was stalled for almost 10 years as Microsoft continued their practices of stomping on any new technlogy which didn't solely support Microsoft Windows.
"When I was testing 10, it also ran fine with Edge, Cortana, Windows Store, and all other unwanted junk forcefully removed"care to share where you found the instruction for this?
Looks like this info is missing...
powershell is your friend here.
Get-AppxPackage will list packages for you
Remove-AppxPackage will remove the packages that you don't want
I'm not sure about removing Edge or Cortana using this however the windows store and much of the utter shite* that is force fed onto Windows 10 systems can be removed. Just beware that because of the shit way the windows store/update process works removing an "AppX" (metro/store) package from a system does not purge the update queue of the bloody thing therefore it will get reinstalled. Wait for all updates to be applied (there is no notice of this, of course, it's entirely invisible) and then run the removal scripts and the things will be gone.
* Some of it it might be good, but force it on me and I'll delete it with prejudice. Also jaded experience indicates that it won't be good...
that thing about the browser and OS being so tightly integrated that it can't be removed was just a story.
Then how come, under XP, when IE hung up, Word and Excel documents wouldn't load, but everything else worked fine? Happened to me loads of times. Luckily my employer finally allowed us to use Firefox, and a lot of problems went away.
In Microsoft world, browser and is are very tightly integrated, it's not surprise you can't uninstall internet explorer or edge.
That was only artificially made that way to help them win a court case they lost anyway (against Netscape, about anti-competitive dumping of a browser and anti-competitive abuse of monopoly). That said, it could be argued they won in Real Life because that took so long to get anywhere near a conclusion that the outcome became pretty much irrelevant, also because the fines for that were then so minute that it amounted to petty cash.
Why do people still run Windows? The answer is "Marketing." That and the 100s of thousands of businesses that run software that they won't spend the money to update or port to anything else. (or for which alternatives on other platforms don't exist) And the MS-based infrastructure in place with the blood still wet on the contract. Stuff like Exchange, Azure, SharePoint, OneDrive, Skype. And now that businesses are using Skype for their main telecom instead of just messaging, the pit grows deeper. The unholy partnerships between big players like Intel, Dell, HP and MS also serve to discourage anyone who dares to think differently when choosing a processor or OS.
I personally use Linux as much as I can at home, and would love to see it more in the home and workplace on desktops, but don't see it changing anytime soon, at least in the US, unfortunately.
"I really don't know why people that don't need to run Windows, still run Windows...."
The same reason people run the default ECU mapping on their cars....
The same reason they keep the same router as supplied by their ISP
The same reason they buy meat from the supermarket.
It's convenient, does the job and they have far more important things to do with their time.
The same reason they buy meat from the supermarket.?
You can buy meat from a supermarket? You guys are lucky over there!
Here we have floor sweepings "flavoured" with sawdust and mixed with red food colouring. I'm not sure what word I'd use to describe it. For it to be "meat" it would have to have a significant number of changes. I haven't yet found a supermarket in NZ that sells actual meat products.
This post has been deleted by its author
Indeed, this seems really strange about this story. In fact, Internet Explorer will not even allow local html files to access other local html files. (Firefox is more liberal in this regard.)
Of course you can change the security settings to allow this but then I'd say it's your own responsibility.
Agreed, this doesn't add up. I'm guessing that people have "proven" this bug by opening an HTML page on their local file system, and having this link in an img tag.
Maybe there's an actual vuln here, but the idea that my website could go crawling around on your file system sounds like a far greater security issue than just this, and would surprise me if two major browsers both failed to protect against it.
I ran the blog link through Google Translate (use Russian as source language, not auto detect, otherwise something goes wrong) and nobody's talking about a browser at all, just how Windows/NTFS works.
The earliest story I can find about this is Ars Technica's and I think this time they got it wrong. Everyone else is linking back to FAKE NEWS!
It worked in Google when I selected from Russian instead of letting it autodetect, as someone here noted (can't find the message now), though many of the comments are still in Russian.
The article discusses the bug in NTFS; I didn't see anything about Firefox in the article. I saw two mentions of Firefox OS in the comments. The bug in NTFS seems to be real, but how did it get to a browser vulnerability between its Russian source and its bleepingcomputer article?
Pretty much every android scare story is fake news too , but it fits the hidden agenda, so nobody calls it out (given 2bn active android devices, we should be seeing loads of real world issues, not just reading about potential ones. I have never ever seen a real world android inadvertent infection, and only deliberate attempts for news story clickbait)
That was a question I had too. If Firefox/IE can access arbitrary files in the client's file system, that seems like a bigger concern than locking the system up. I tried to read more about it, but the site's in Russian, and neither Google nor Bing were willing to translate it for me. I can get Firefox to access local files from the URL bar, but I would not expect it to be able to do that from a remote page.
Is it possible that this is another Windows bug being cast as a browser vulnerability, like the thing where Chrome faithfully downloads a .scf file when requested, and that's a security flaw? If the browser can really be made to access the file system with a simple file:/// reference, it would seem that it would have been exploited already (a lot).
Well, if you want a stream of thoughts on the subject, I found this link at least demonstrated some people were aware of the actual situation: https://news.ycombinator.com/item?id=14422706
Long story short, it's all a storm in a teacup. To actually do something with this you would need a user to download an HTML file and run it locally. If you can get someone to do that, you'll probably be doing something far nastier than locking up their PC.
"To actually do something with this you would need a user to download an HTML file and run it locally. If you can get someone to do that, you'll probably be doing something far nastier than locking up their PC."
Like in an email? Maybe using a fake "you email client doesn't support HTML, click here to poen in your browser" type of attack?
Yes, exactly that. It would require a phishing or similar attack to first breach security. At which point they are unlikely to decide to prank the user with this, they will install ransomware.
To emulate the subtitle - "The nineties called, they want their benign hackers back."
Multiplied by the lack of "validate user input whenever a user can enter data"
You can skip that sort of data entry checking provided you know 2 things.
1) The data will only ever come from other software
2) That software will never make a mistake.
In our universe the odds on bet is one or other of those statements will be false.
The fundamental problem here is that a container for internal state for NTFS appears as a file in the file name space.
The ODS-2 Files-11 file system format used by VMS (a development of the earlier RSX-11 ODS-1 format) had exactly the same conceptual mistake, with dellghts like BADBLK.SYS and INDEXF.SYS in the root directory. Indeed, INDEXF.SYS is the analogue of $MFT. It's not surprising that NTFS continues this, because ODS-1 and ODS-1 are said to have been designed by Dave Cutler, who Microsoft hired as the NT team leader.
It's disappointing, though, that no lessons were learned. Perhaps memory is playing tricks on me after 30 years, but this locking exploit sounds awfully familiar to me from the days when my job required passing an eye over VMS security updates before we applied them. At the very least, a good "second system" design should have cleared this cruft away.
> Wondering why your post got 3 downvotes. It was spot on.
Probably because criticising VMS on El'Reg is considered illegal.
The Veritas filesystem doesn't put the structural files into a set with any names, so normal accesses can't see them. You need to do into a filesystem debugger before you can get at this stuff. I can't see any benefit to linking these things into a normal file name space.
"I can't see any benefit to linking these things into a normal file name space."
I agree. That said if a benefit were to be had it should be possible to come up with a scheme that does not allow/require userland to hold any form of exclusive lock on it. I suspect that the folks who came up with the scheme didn't consider deadlock - which is plausible if you have a bunch of folks working on filesystem format who weren't familiar with running code in parallel, deadlock and VMS (quite plausible given the state of the job market and timeframe for NT).
"At the very least, a good "second system" design should have cleared this cruft away."
In theory yes - and Brooks law does apply to so many aspects on NT - but in the 70's most programmers were well aware of how the operating system worked and had no interest in crashing it - if we wanted fun we'd play with the light patterns on the front panel or set up a loop to play "Daisy Bell" on any nearby radios.
But then computers because a commodity and the script kiddies sent the world downhill.
"The ODS-2 Files-11 file system format used by VMS ... had exactly the same conceptual mistake, ..."
Indeed, INDEXF.SYS is the analogue of $MFT. It's not surprising that NTFS continues this, because ODS-1 and ODS-1 are said to have been designed by Dave Cutler, who Microsoft hired as the NT team leader."
I suggest this may possibly give grounds for HP (the owners of DEC VMS IP) to demand to see Windows source code etc. as perhaps Dave Cutler took more with him than just what was in his head...
> I suggest this may possibly give grounds for HP (the owners of DEC VMS IP) to demand to see Windows source code etc. as perhaps Dave Cutler took more with him than just what was in his head...
They already did that a couple of decades ago. They threatened to sue over NT and extracted a settlement from MS alleged to be $100million plus other items:
http://windowsitpro.com/windows-client/windows-nt-and-vms-rest-story
""""Why the Fastest Chip Didn't Win" (Business Week, April 28, 1997) states that when Digital engineers noticed the similarities between VMS and NT, they brought their observations to senior management. Rather than suing, Digital cut a deal with Microsoft. In the summer of 1995, Digital announced Affinity for OpenVMS, a program that required Microsoft to help train Digital NT technicians, help promote NT and Open-VMS as two pieces of a three-tiered client/server networking solution, and promise to maintain NT support for the Alpha processor. Microsoft also paid Digital between 65 million and 100 million dollars."""
The fundamental problem here is that a container for internal state for NTFS appears as a file in the file name space.
No, the problem is not exposing internals as files (that's a convenience found in many systems [/dev , /proc anyone?]), but in not properly securing said internals.
I think you'll find MS hired quite a few others from his core team.
It's not that this component is visible, it's what ordinary users are allowed to do with it without any special safeguards.
People have looked at NT and noted it's close similarities to VMS in the data structures it uses and even its function call names.
However aren't most of the desktop Windows from a later, not NT code base? Testimony that the core data structures of an OS can long outlive the first implementation of the functions that manage them.
However aren't most of the desktop Windows from a later, not NT code base?
No. Windows 1.x, 2.x, 3.x, 95, 98, and ME are the non-NT desktop Windows versions.
Windows NT 3.x, 4.x, 2000, XP, Vista, 7, 8 and 10 are all based on the NT kernel (with various pieces added/removed/rewritten over time.) 2000 was the last NT version which used the same name/number for server and desktop versions, but Server 2003 is based on the same major kernel as XP, 2008 is based on the Vista kernel, 2008R2 on 7, 2012 on 8, and 2016 is based on the 10 kernel.
Early UNIX used to only export the state of things via the /dev/mem and /dev/kmem files, which mapped the whole system's memory, and the memory image of the kernel respectively. It was normal to open /unix and extract the symbol table and then open /dev/kmem and seek to the location of the kernel data structure you were interested in.
These files were set so that you had to be real or effective ID of root in order to read them, and it was drummed into admins that they did as little as possible when logged into root to reduce risk of inadvertent or malicious damage to the system. Scribbling over either file would more than likely crash the system, or at least some of the processes.
I remember many years ago there was a bug in the UNIX Version 7 TU11 driver that would render a tape drive unusable. I used to open /dev/kmem read-write with db or cdb (can't remember which) in order to manually unset the lock to allow me to use it again without rebooting. I don't think I ever identified the cause of the drive being locked.
Later in UNIX, syscalls were added to give more guarded access to a number of kernel data structures.
/proc was a Linux thing that makes some operations much easier, and has been adopted by some UNIXs. /sys may follow, but I don't think anybody's ported, or likely to port, /udev, dbus or kms to UNIX.
It's a local attack, not a remote attack. It needs to be fixed for sure, but is hardly the end of the world. Local attacks get discovered on other OSes too with depressing regularity.
Finally, I observe that this merely allows a local user to crash the system. I suspect that on the vast majority of Windows systems, the local user has in fact the privilege to *shut down* the system, which pretty much has the same effect...
At one point (I think it's the chapter on macro procssing) they put in a print statement saying "Can't happen"
Later they comment that "Can't happen" got printed out quite a lot when they were writing the code.
Can not, does not, will not. You hear those a lot.
Except when they do.
I'm not a fan of Windows but somehow I cannot believe this is not fake news. What is the CVE number of this bug? It is nowhere to find! What is the Bugzilla bug number of the relevant Firefox bug? I've checked: there is none. Not even a closed INVALID bug.
So why should I believe it is a real bug?
This post has been deleted by its author
I found the fastest way on Windows 7 was to open a cmd window and type
start c:\$MFT\123
Then I can't open another file on the system and pretty much everything locks up.
To remotely exploit you would seem to need the root of a drive shared or a domain account that can open admin shares:
start \\machine\c$\$MFT\123
Looking into it a bit, does anyone have any insight on if it would be possible to intercept and thwart exploit attempts against this with a filesystem filter driver? If so, i wouldn't be too surprised if the anti-malware groups are working on something of the sort (their software already tends to use those sorts of techniques).
Until Microsoft patches this problem, use Chrome: a slip in file-path handling allows attacker to crash Windows 7 and Windows 8.1 with a file call.
There is an easier fix: stop using Windows. I've said this a gazillion times before: planning to abandon Windows and Microsoft altogether is the most effective way to sharply reduce security risks and TCO and up productivity. If you calculate a complete TCO which takes into account resource costs you to keep things running and license-compliant versus any other OS you can even afford Macs and training.
Sure, it means your management will get fat for a while being wined and dined to death by Microsoft reps to prevent this from happening (why do you think government ministers are so fat?) but the naked facts don't lie. It's a good thing for Microsoft that most larger companies are owned by a committee, which means they're pretty much paralytic when it comes to taking intelligent decisions, but I see a lot of this already happening in private banks where they DO have the people who can work with numbers and IT at the same time, and they're small enough not to show up on Microsoft's "we're losing the faithful" marketing radar.
Yes, I am a cynic. I've watched this electronic snake oil being peddled for some decades now. Originally there were no viable alternatives, but there are now and the electronic world has gone dangerous enough to pay attention to them, especially since Microsoft is behaving like being hacked is perfectly normal. Well, it isn't.
"Until Microsoft patches this problem, use Chrome: "
Other Chromium browsers include Opera (beta) and Vivaldi. I prefer both over Chrome. I'm still at sea over the non-Chromium browsers Otter and Sleipnir.
To be honest, when I first saw the quoted line, I thought the instruction was to type Chrome: in the browser address line, followed by code that every El Reg reader except me would know.
The described vuln seems like a third- or so cousin to the bug / annoyance which exists at least as late as Windows 7, whereby you ask to dismount say a USB drive, Windows replies that it's in use by another process ... and even if you close everything you can close in Process Explorer, Win still doesn't give you permission to unplug. Windows doesn't seem to know which process has locked your device. At least in the analogous "won't sleep" situation, you have powercfg -requests. Ow. It feels so good to hit this injured ow hand with a hammer. Ow. Sooooo good.
"There is an easier fix: stop using Windows."
Sigh, get out of cloud cuckoo land. For your sole, individual box, this may be true. For those of us who run IT departments in the real world, it is not.
Moving 10,000 boxes over to Linux (or paying twice as much for Macs), retraining 10,000 non-tech staff to use Linux/MacOS, finding suitable replacements for the (still vast catalogue of) software that does not run on Linux (or literally cannot run on shitty Mac gfx hardware), and then hiring a bunch of Linux support staff on roughly twice the wage of their Wintel equivalents (or random people to carry shit to the Apple "geniuses') is not an 'easier fix' than just shunting users onto Chrome for the 3 weeks until MS patch this bug.
Sigh, get out of cloud cuckoo land. For your sole, individual box, this may be true. For those of us who run IT departments in the real world, it is not.
We found the 3 year TCO quite convincing (which got us the budget for trials and planning), but the main reason why conversion for us was less hard than the average setup was that we had a backbone readied for a wave of M&A so we were already wholly Open Standards at the core. If you still have to get there it will indeed take longer.
The main challenge was learning estate management the Apple way, but we cheated using Snow software instead. That had as major disadvantage that we still had to run a couple of Windows servers (it's not offered on a safer platform) but we run that in firewall controlled VMs so it's kept reasonably safe.
Emotionally it's less of a sell - execs like shiny, so if you help them with the numbers to justify the expense you don't have to push *too* hard :). The main challenge is to keep it all under wraps so that Microsoft doesn't find out too early (which is rather hard work in itself).
Once you're past the first wave of conversion and you can point at Yet Another Problem that you thus dodged (WannaCry, for instance, has been good for us), management is generally OK with it. The one thing, however, that you cannot get rid of is Outlook, and usually Office in general. The only thing you can do there is lock it down tight, but it remains a risk.
This phenomena even has a name. It's called the "Normalization of deviance" and was noted as a feature of the root cause of the Challenger Shuttle disaster. Because there are no major repercussions people start accepting a state of affairs that deep down they know to be wrong.
I wonder why XP formatted NTFS systems were not vulnerable to this $MFT exploit. $MFT can't even be found on the root drive of XP machines. Is this a secret additional feature of Vista, Win7 and Win8.1? As suggested above by someone, to exploit this just run c:\> start c:\$MFT\123 but I did that too and only a message box was shown wit a red x icon and ["Windows cannot find 'c:\$MFT\123'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search."] I can't trigger this in XP.
>> run c:\> start c:\$MFT\123 but I did that too and only a message box was shown wit a red x icon and ["Windows cannot find 'c:\$MFT\123'
Now repeat the command. I'm on 7. The first time, I too get 'not found', and no other symptom. But if I enter it again, the machine locks up.
I did it again more than 30 times in a row, nothing happened. The same msgbox is shown,and also a message at the command prompt "The system cannot find the file c:\$MFT\123.".
Maybe the comment just after my post was correct. Probably related to PowerShell and only Vista up to Win8.1 is affected.
One reason XP is not affected is because on XP, remote (SMB) files are not locked on execution. You can "start" $MFT as many times as you like: if it's on a "share", it's not going to be locked.
There are other differences between the locking behavior of Win 5.x and Win 6.x, so there may be other factors involved as well.
I wonder why XP formatted NTFS systems were not vulnerable to this $MFT exploit. $MFT can't even be found on the root drive of XP machines. Is this a secret additional feature of Vista, Win7 and Win8.1?
OK, I accept there's a difference between correlation and causation, but AFAIK Win 7 and beyond no longer had EDLIN.EXE. Clearly that played a far more important role than previously known.
:)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
