Microsoft is working on a patch for a bug or feature in Windows 10 that allowed access to the command line and, using a live Linux .ISO, made it possible steal BitLocker keys during OS updates.
The command line interface bypasses BitLocker and permits access to local drives simply by tapping the Shift and F10 keys.
BitLocker …

Re: This, because we can't overwrite files that are in use.

Your disk is not actually encrypted using your password... Your disk is encrypted with a symmetric encryption key, that key is then encrypted again, and then your password encrypts THAT key.

When bitlocker is disabled, the symmetric key used to unlock the disk key is stored in plain text in a special partition on the boot. This allows it to unlock the drive without your password, until that key is then deleted.

It's a fairly terrible oversight... Here's MS's own technet article:

"Exposing the drive master key even for a brief period is a security risk, because it is possible that an attacker might have accessed the drive master key and full drive encryption key when these keys were exposed by the unencrypted key."

Re: This, because we can't overwrite files that are in use.

Re: This, because we can't overwrite files that are in use.

Your disk is not actually encrypted using your password... Your disk is encrypted with a symmetric encryption key, that key is then encrypted again, and then your password encrypts THAT key.

Yeah, I figured it'd be along those lines… whether they store the passphrase or the key unencrypted is immaterial, all the knowledge needed to access that key is available on-disk in a form that allows unauthorized access (by the OS or other parties).

They could encrypt it 10 or 20 times if they wanted … all that is blown the moment they store any one of those keys or the passphrase in cleartext.

Re: This, because we can't overwrite files that are in use.

The W10 1607 update seems to have real problems with drive encryption generally. This laptop and the one on my desk use HP's drive encryption and now everyday I get a nag from Windows saying an update failed. If I go through the fix it process then eventually it comes back and says that I need to remove the encryption SW, which means I need to decrypt the whole disk then once that has happened I can remove the SW and then I can update after which I would need to reinstall the encryption SW and re-encrypt my disk. Yeah like thanks guys. Just pull your F*&^ing fingers out and sort this, it isn't funny.

Re: This, because we can't overwrite files that are in use.

No you don't.

You need to remotely have the system request the password of a user who has the ability to create the clear text key, you then save that key, get to the system whenever you want (and however you want); put the key back; reboot it.

It reboots back up, and unencrypts the drive for you while it does it.

Re: This, because we can't overwrite files that are in use.

What this means is that bitlocker is basically broken. Steal laptop with WIndows 10, wait for the upgrade, plug it in, wait for it to get the upgrade, get key -> data!

I guess it would probably be easier to boot Linux, use data-recovery to recover the key on that other partition -> decrypt main partition -> data! Testdisk, anybody ? Ok, if bios is protected, as should be, plug drive into your Linux box.

I wonder if undelete would do it from within another windows box ?

Both last two cases, using data-recovery, just need a laptop that has been upgraded to a new Windows 10 build in the past. I guess Windows 8.x had the same feeble-minded vuln, so any Windows 8+ laptop, they would not implement encryption without the possibility of easily gaining access to the data, surely a federal requirement drawn up in one of Murika's secret courts, or simply dumb-c*nt devs, after all, they are Microsoft for a reason™!

Re: This, because we can't overwrite files that are in use.

"Which is the prime reason the updates have to be applied during boot up anyway."

In the POSIX world, a directory entry is simply a pointer to an INODE, which represents "the file". An 'overwrite' of a file that's in-use simply points to a different INODE. Then, subsequent 'opens' of that file use the NEW version (and not the old one). The old inode is kept around on the file system until the last reference to it closes, and then it gets deleted. [this would keep running processes from crashing, for example, if you swapped in a new shared lib before restarting them, and when they re-start, they automatically use the NEW one].

Micro-shaft, on the other hand, ENCOURAGES multiple processes to be able to directly muck with the same file, using a sharing system that MOST LIKELY creates a LOT of inefficiency inside the kernel.

Hence, file I/O on a POSIX system appears to be FASTER than on an equivalent windows system [at least, that's been MY experience].

I sometimes refer to the WORST of this as "paranoid cacheing", i.e. the apparent assumption that "something came along" and changed what was on the hard drive behind your back, and now you have to re-re-read the same block from the physical file, again, even though you just wrote it BACK to the file a few milliseconds ago... [seems to happen most often wirh the registry, most likely due to excessive 'layering' and ".Not"-ishness]

.So, *NOW*, this file-system philosophy of Micro-shaft's is *BITING* *THEM* in the backside, with respect to the hoops they have to jump through when Bitlocker is in use.

/me is now thinking of some terms involving a circle, a cluster, and 'Situation Normal'

Re: This, because we can't overwrite files that are in use.

If the laptop was cold when this happened, it would still be secure, as you could not boot into the operating system to allow it to start the update process. The master key is usually only exposed when the system is fully booted.

Re: This, because we can't overwrite files that are in use. @Dazed

This laptop and the one on my desk use HP's drive encryption and now everyday I get a nag from Windows saying an update failed. If I go through the fix it process then eventually it comes back and says that I need to remove the encryption SW, which means I need to decrypt the whole disk then once that has happened I can remove the SW and then I can update after which I would need to reinstall the encryption SW and re-encrypt my disk.

In short: MS has brought about a security change and HP is unwilling to support the Drive Encryption component any longer, and it will never work with 1607, aka Win10 Anniversary Update.

It's a real pity since the HP Client Security was easy to use and integrated all the way to BIOS and supported pre-boot authentication with fingerprints and smart cards. (and still does, but losing the drive encryption is a big blow).

My guess is that since HP has licensed the encryption part from a 3rd party they would have had to re-license a newer version and it wasn't financially justified...

Re: This, because we can't overwrite files that are in use.

It may be a terrible oversight but it may also have no remedy. It possible that disabling bitlocker is required because the actual upgrade is performed in WinPE (that can't get the key from TPM) or maybe because major changes to the system can result in bitlocker lockout (where manual entry of the key is required). So Windows suspends the BL for the upgrade and resumes it after next boot to Windows (since 8 it's SOP anyway) when new system can re-establish trust with TPM (and prevent lockout at the next reboot). Just a guess, but I'm curious if the same process would take place in SP1 update to Windows 7 and 8.1 upgrade from 8.

Re: @Daniel

Usually, that is true as long as the computer is off. Once it is on, and something needs to access files, keys needs to be somewhere readable. The issue here is they are in clear text and accessible outside the upgrade process.

Re: @Daniel

You both have a point.

There should be no access to encrypted storage without the user permitting it which, for reasons of update and patching, means that it would be best if the system is separated from the user data (which is easy in Linux systems that use a separate partition for /home, but that's not a common default).

On the other hand, you will also need to protect system files, and only undo that protection come patching time which is then a separate process. That said, I prefer to see the patching rather than let it automate overnight, and that's independent of platform, Linux, OSX or Windows.

Re: @Daniel

"Linux & BSD have also had their fair share of local exploits."

NONE of which involved *FORCED* *UPDATES* as I recall... and when it happens to Linux or BSD, you get *HEADLINES* like plane crashes vs car crashes... [and Micro-shaft would be the 'car crash' equivalent - ANOTHER vulnerability? Eh, no surprises...]

Whole-disk encryption is silly anyway

The OS files (which are the ones that MS wanted to update in this case) are not secret. The ones you actually want to protect are the per-user files, which MS never need to update and so they can be encrypted with a mechanism that doesn't need to have a back-door designed into it.

Traditionally, the objection was that Windows failed miserably to separate system files and user data, but that's actually been getting better (slowly) over time. These days, I suspect that *most* Windows apps can tolerate a setup where directories are either per-user-encrypted or read-only-for-that-user.

Re: Whole-disk encryption is silly anyway

Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place.

Re: Whole-disk encryption is silly anyway

"Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place."

Yes, but TBH, you'll still need physical access to the machine unbeknownst to its owner which isn't the domain of script kiddies or your normal hacker, we're talking espionage here. And of course once you have the machine + the skills of a government agency behind you then all bets are off since installing special hardware to intercept data is well within their abilities.

Re: Whole-disk encryption is silly anyway

Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place.

Ah, but therein lies a little problem: whole disk encryption is unhelpful when the specific user does not shut down the system, but merely puts it into suspend/sleep mode. At that point, you have the equivalent of an open safe in an office with a locked door: far less protection than you think. That's not just the case with Windows, but also with OSX, sorry, macOS FileVault, and there is no warning to end users that this is the case (or an option to disable sleep in favour of shutdown, which swaps a risk of disclosure with one for lost work because you were away from your system too long - you can't really win).

I prefer the Linux idea of having a separately encrypted /home/user partition, but even that doesn't cope well with sleep/wake cycles insofar that it leaves the crypto door open until shutdown.

In short, crypto is fine, but you still need to have some idea of what does what to make the right choices and get the benefit from it that you require for your specific needs. It's not something you can just hand to Joe User who needs to keep things safe, a bit of discussion and education is still needed.

Re: Whole-disk encryption is silly anyway

If your "evil maid" shows up, it's too late. The only time she comes around is when you have given her a home in the environment ,and to do that, you've already decrypted the environment.

If you need to encrypt an entire disk, you really just need better plain old directory/partition management, it's just that simple. Of course this is easy to say for a UNIX user, but as mentioned, Microsoft users are stuck with file management thoughts like "Why the fuck is it there?" or "Where the hell did it go?" or "It looks like a directory, so why isn't it?"

Re: Whole-disk encryption is silly anyway

And that would be (one reason) why /home should always be a separate partition. I do the same thing on all my application directories for my servers.

Each parition is encrypted with a separate password. I have the system set up so that /, /bin, /dev, /etc, /root, /sbin, and a /util (Which contains scp, curl, and a few other utilities). That way the server admins can patch, upgrade, and manage the system and only need to know a single de-cryption password and even knowing the root pass, do not have access to sensitive data. Application owners, on the other hand, only know the passwords to decrypt their password's partition and neither the root or / decryption password.

Each application is chroot'ed with its own set of directories (such as /etc, /sbin, /var, and so on), so the application owners can do what they need to their partition without affecting anything else.

Re: Whole-disk encryption is silly anyway

That's not just the case with Windows, but also with OSX, sorry, macOS FileVault, and there is no warning to end users that this is the case (or an option to disable sleep in favour of shutdown, which swaps a risk of disclosure with one for lost work because you were away from your system too long - you can't really win).

You haven't googled it, then.

pmset -a hibernatemode 25

pmset -a destroyfvkeyonstandby 1

Which indeed changes the "sleep" to "hibernate" and destroys the FV key from memory. Thus the RAM won't have it, and the swap file with the RAM state won't have it either. Sure, you need to enter your password on "wake up" but it's worth the extra security.

Re: Whole-disk encryption is silly anyway

You haven't googled it, then.

pmset -a hibernatemode 25

pmset -a destroyfvkeyonstandby 1

Thanks for that, hadn't gotten round to look at that last loophole but you saved me time by putting me on the right path (and a Godawful amount of Googling because there's a bit more to it due to powernap settings and other challenges but I think I've caught all of it now :) ).

And no, I won't use a Yubikey. I prefer adding OTP capability because they're not dependent on having any physical to the hardware..

I would appreciate it if Microsoft didn't decide to not inconvenience me when I have clearly elected to be inconvenienced. Please assume that I know what I am doing, and have good reason to do it when I use things like BitLocker, etc.

I mean, just ask for the bloody key on boot time, same as you would in any other case the machine is rebooted. What's wrong with that, Microsoft...? What's wrong with that?

What's wrong with that, Microsoft...?

Requiring the password be entered again during the upgrade process means that you can't do remote (unattended) upgrades, which is kinda important for companies managing tens of thousands of Windows desktops.

Re: What's wrong with that, Microsoft...?

Anyone doing remote/unattended upgrades should be capable of reading the articles on how to do this manually, create a clear key and save it to the drive - along with the appropriate warnings about doing so (I'd be worried if anyone has un-monitored access to their physical servers anyway).

Doing it by default is just plain ignorant, stupid and possibliy malicious.

It's not impossible for me to have dns claim my server is updates.microsoft.com (or whatever the address is now) and tell windows I have a 'new upgrade' package for it to install. Suddenly this looks very dodgy indeed.

Re: What's wrong with that, Microsoft...?

"Anyone doing remote/unattended upgrades should be capable of reading the articles on how to do this manually, create a clear key and save it to the drive - along with the appropriate warnings about doing so"

Re: What's wrong with that, Microsoft...?

"[T]ens of thousands of Windows desktops" with BitLocker deployed?

Are you sure that's a real scenario?

Even if it is, shouldn't something be worked out using AD instead of storing cleartext decryption keys on the local machine...? Or, if that's impossible, for whatever reason, shouldn't enabling this "feature" require an admin flipping something in a GPO or something? Some sort of opt-in? If all of that is impossible, shouldn't this be well-documented by Microsoft, to let people know that there's this tiny security hole they should consider?

This is not a bug. This is a "feature" of a security system that completely and totally obliterates it, in certain scenarios. It didn't happen by accident. Someone sat down and engineered this. And any number of other people signed off on it.