back to article SHIFT + F10, Linux gets you Windows 10's cleartext BitLocker key

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 …

  1. Anonymous Coward
    Anonymous Coward

    No other place to put this

    The El Reg commenting platform is now hopelessly broken on Chrome on Android which, as you endlessly report, is most of everybody. How do you not know this? It has been a week at least.

    1. Anonymous Coward
      Anonymous Coward

      Re: No other place to put this

      Use Firefox instead? (With Ublock Origin - makes for a much nicer browsing experience).

    2. This post has been deleted by its author

      1. Anonymous Coward
        Anonymous Coward

        Re: No other place to put this

        you lot are supposed to be at work in the I.T industry.

        surely you have proper computers to read el Reg from?

        I find a 21" screen for better than a 4" screen for reading on

        1. M man

          Re: No other place to put this

          ....or three

      2. davidp231

        Re: No other place to put this

        "Out of curiosity, how? Posted from Chrome on Android."

        How? Simple, it's not Chrome.

        Chrome has only one use in my eyes, and that's for watching Netflix under Linux. First thing I do when setting up a droid phone is disable all the bloatware - Chrome included.

        1. Lord_Beavis
          Linux

          @ davidp231 Re: No other place to put this

          "Chrome has only one use in my eyes, and that's for watching Netflix under Linux."

          I'm using Firefox (with uBlock Origin) and the User Agent Overrider and this in the preferences:

          Linux / Chrome 53: Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/53.0.2785.34 Safari/537.36

    3. Marco Fontani

      Re: No other place to put this

      The El Reg commenting platform is now hopelessly broken on Chrome on Android

      Would you be able to share more details about this? e-mail webmaster@ please and we'll see how we can help!

  2. Anonymous Coward
    Anonymous Coward

    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. And how does it know the passphrase to unlock the disk to perform those updates?

    Maybe I'm a little naïve about how BitLocker works, but if it can just unlock the drive at will for OS updates, then I have serious questions about how truly secure it is.

    1. Anonymous Coward
      Anonymous Coward

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

      1. AMBxx Silver badge
        Black Helicopters

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

        But it needs you to have the PC rather than a remote hack.

        Sounds almost intentional - Microsoft's offering to government agencies?

        1. DJ Smiley

          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.

        2. Mage Silver badge

          Re: Physical Access

          All security bets are off anyway with local / physical access.

          It's only an issue if it's via the LAN.

          1. Prst. V.Jeltz Silver badge

            Re: Physical Access

            I thought encryption was pretty much FOR local access - ie stolen / lost laptops

            If you're accessing a machine via LAN you've probably completely sidestepped the drive encryption.

            1. M man

              Re: Physical Access

              That was my though....What else IS bitlocker for?

        3. John H Woods Silver badge

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

          "But it needs you to have the PC rather than a remote hack." -- AMBxx

          The main purpose of whole disk / volume encryption is to protect the contents from people who have gained physical access to the computer.

      2. Anonymous Coward
        Anonymous Coward

        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.

      3. The Man Who Fell To Earth Silver badge
        WTF?

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

        "... until that key is then deleted."

        I hope you really mean "... until that key is then physically over written a bazillion times." Otherwise, it's still there for anyone to find if they know where to look.

      4. Hans 1
        FAIL

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

        This is even worse, ever heard of undelete ?

        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™!

        1. Anonymous Coward
          Anonymous Coward

          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.

          If the system is turned on at the time, it's different.

      5. joed

        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.

    2. Dazed and Confused

      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.

      1. Sandtitz Silver badge
        Unhappy

        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.

        HP has an advisory document regarding this problem.

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

        1. Dazed and Confused

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

          > HP has an advisory document regarding this problem.

          Oh B*&^^&*r

          > but losing the drive encryption is a big blow

          You can say that again.

          Pity they didn't tell me.

          Pity they didn't tell me before I bought this laptop in June. It's a EliteBook Folio 1040 G3, which isn't on the list, but I assume it's being clobbered by the same issue.

          Thanks

          1. Dazed and Confused

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

            > Oh B*&^^&*r

            Oh double triple B*&^^&*r

            That advisory has just been followed up with. c05348215

            Saying that you can't use HW encryption with bitlocker.

            Now I just want to scream!

    3. bombastic bob Silver badge
      Devil

      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'

  3. Daniel B.
    FAIL

    All those MS apologists are hiding

    This is almost like the Linux boot vulnerability ... except this one can actually expose the master keys and thus open up your entire "encrypted" filesystem. Way to go, MS!

    1. Anonymous Coward
      Anonymous Coward

      Re: All those MS apologists are hiding

      Yep, 'least with the Linux one, the partitions remained encrypted.

    2. Anonymous Coward
      Anonymous Coward

      @Daniel

      Well, this isn't something limited to Microsoft you know. Linux & BSD have also had their fair share of local exploits.

      Which is why I think your comment isn't fully fair. I mean: no computer is safe when an attacker has physical access. Including those which have applied HD encryption.

      1. Dazed and Confused

        Re: @Daniel

        I mean: no computer is safe when an attacker has physical access. Including those which have applied HD encryption.

        The data on your disk should be safe if the encryption is any good (ie doesn't have a May door). That's the whole point of encrypting the thing.

        1. Anonymous Coward
          Anonymous Coward

          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.

          1. Anonymous Coward
            Anonymous Coward

            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.

      2. bombastic bob Silver badge
        FAIL

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

  4. Ken Hagan Gold badge

    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.

    1. Paul Crawford Silver badge

      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.

      Assuming your password is not known to the main, of course...

      1. Anonymous Coward
        Anonymous Coward

        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.

      2. Anonymous Coward
        Anonymous Coward

        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.

        1. Anonymous Coward
          Anonymous Coward

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

        2. Daniel B.
          Boffin

          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.

          1. Anonymous Coward
            Anonymous Coward

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

      3. oldcoder

        Re: Whole-disk encryption is silly anyway

        Wasn't that the purpose of Microsoft signed binaries? The "modified" binaries shouldn't work...

        I guess this is just another Microsoft screwup.

        The standard substandard Microsoft insecure security...

    2. Crazy Operations Guy

      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.

  5. RIBrsiq
    Facepalm

    Security is a trade-off. Usually with convenience.

    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?

    1. Roger Lipscombe

      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.

      1. DJ Smiley

        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.

        1. Anonymous Coward
          Anonymous Coward

          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"

          Rinse and repeat 10K times. Err, no thanks.

          1. Anonymous Coward
            Anonymous Coward

            Re: Rinse and repeat 10K times. Err, no thanks.

            Hi, my name's Al, I'm from a well known vendor of Virtual Desktop Infrastructure.

            I believe I have a cost-saving and labour-saving opportunity for you.

            Call me.

            1. Steve Aubrey
              Happy

              Re: Rinse and repeat 10K times. Err, no thanks.

              "Hi, my name's Al, I'm from a well known vendor of Virtual Desktop Infrastructure.

              I believe I have a cost-saving and labour-saving opportunity for you.

              Call me."

              My number's 867-5309. You can call me, Al.

              - Jenny

          2. Daniel B.

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

            Rinse and repeat 10K times. Err, no thanks.

            You mean it can't be done through GPO?

          3. Kiwi
            FAIL

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

            Rinse and repeat 10K times. Err, no thanks.

            So you'd rather have 10k of your machines have an easily recoverable clear-text decryption key sitting on the HDD?

            Oh, of course. You promote MS products. You obviously have no clue what "security" is.

            (El reg, can we have a "the previous poster is a completely clueless idiot" icon please?)

        2. Anonymous Coward
          Anonymous Coward

          Re: "dns claim my server is updates.microsoft.com"

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

          Oh no. Surely not? You're not suggesting.... no, it's unthinkable.

          Somebody please tell me there's more (preferably with a little bit of detail of *what* the "more" is).

          1. Ken Hagan Gold badge

            Re: "dns claim my server is updates.microsoft.com"

            You can certainly call yourself updates.microsoft.com if it floats your boat, but I suspect you will have more trouble pushing out "updates" that have been signed by a key that the target machine trusts for this purpose.

            1. Crazy Operations Guy

              Re: "dns claim my server is updates.microsoft.com"

              "that have been signed by a key that the target machine trusts for this purpose"

              Yup, the OS will only trust updates that have been signed using the same key as the kernel and base libraries were signed with. This is to stop people trying to spoof the Windows update servers and even going so far as to cut certificates that the client trusts.

              If you can somehow manage to either replace the kernel and the base libraries with version you wrote and signed yourself, or somehow managed to figure out Microsoft's 4096-bit code signing key, then you can perform much better hacks than impersonating the update servers...

              1. RIBrsiq

                Re: "dns claim my server is updates.microsoft.com"

                >> "Yup, the OS will only trust updates that have been signed using the same key as the kernel and base libraries were signed with".

                I thought of this, and I'm not sure it will save the day, really.

                I don't know the details of the link to Windows update itself -- I always figured the digital signatures on the updates themselves are enough, so I didn't bother to dig any deeper. But certainly the link to local WSUS is not usually HTTPS; though it can be.

                You see, the update itself can be perfectly legit! Just so long as it will trigger this behaviour, it can be used to effectively remove BitLocker.

                I mean, it doesn't affect me, so far as I can determine, because I'm a paranoid basterd. But this one is an Epic Fail worthy of the great Bloody Stupid Johnson himself!

            2. Kiwi
              Coat

              Re: "dns claim my server is updates.microsoft.com"

              that have been signed by a key that the target machine trusts for this purpose...

              ...that's probably freely available, in clear text, on ourshitissoinsecureitsnotfunny.microsoft.com...

      2. Anonymous Coward
        Anonymous Coward

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

        They could have implemented their bitlocker network unlock feature in the upgrade process. So when its connected to the corp network, then no password, pin etc is needed to unlock the bitlocker drive.

        *Does require support from the BIOS.

      3. RIBrsiq

        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.

        I, personally, would be very happy to see all of them fired.

  6. Halfmad

    Hold up - Microsoft are covered on this one folks!

    The clever sods makes sure you never know when a bloody update will happen, making it FAR harder to do this.

    Sly buggers.

    1. bombastic bob Silver badge
      Pirate

      Re: Hold up - Microsoft are covered on this one folks!

      "The clever sods makes sure you never know when a bloody update will happen, making it FAR harder to do this."

      then I connect a network sniffer, watching for "upgrade" net traffic, to something that powers off the box or at least alarms you to go over and pay attention to it...

      these things can be defeated. Also may be possible to trigger an update by mucking with the clock

  7. djvrs

    Windows 10 Advent Calendar

    A bug behind every door

    1. Captain Badmouth

      Re: Windows 10 Advent Calendar

      Does it end at Christmas?

      ( Ans. : No)

  8. Anonymous Coward
    Trollface

    No surprise

    Linus's shareware OS is a security risk!

    1. anonymous boring coward Silver badge

      Re: No surprise

      "Linus's shareware OS is a security risk!"

      Care to elaborate? If you know what you are talking about, that is.

      You do realise that software where we have no access to the source code can and often do a lot of stuff that we don't have any control over. Windows 10 is a recent example.

      P.S: Wasn't the term "shareware" retired about 15 years ago? Linux is "open source".

      How you download it is irrelevant, but most download it from an official distro's website.

      1. David 132 Silver badge

        Re: No surprise

        @Anonymous Boring Coward: ignore JJ Carter, he's just a troll, desperately seeking attention. Don't feed him.

        1. anonymous boring coward Silver badge

          Re: No surprise

          " ignore JJ Carter, he's just a troll, desperately seeking attention. Don't feed him."

          That's so sad. Especially during Christmas. Isn't there some organisation that can help such trolls?

  9. Crazy Operations Guy

    And this is why I prefer OpenBSD's approach to Disk Encryption

    No recovery keys, no backdoors, only the password/keydisk you used to create it will work[*]. If you lose the authentication method, well, you do back up your data, don't you? The encryption key is never stored as plain-text, only the encrypted version. The only time a plain-text version of the key exists on the system is after the user inserts the keydisk or types in the password in which case it only exists in a highly-protected region of memory and is overwritten with random data when the volume is unmounted. The region in memory it is stored is also used for all the other secrets the kernel keeps around and has quite a few protections looking after it.

    [*] provided you haven't changed the password since creating it, in which case, only the most recent password/keydisk will work.

    1. RIBrsiq

      Re: And this is why I prefer OpenBSD's approach to Disk Encryption

      There's a lot to recommend stand-alone FDE with no backdoors or recovery options whatsoever. But it's not appropriate for a corporate environment where multiple entities may have legitimate claim to the data. There needs to be a way to recover even if the day-to-day key is "lost".

      1. Crazy Operations Guy

        Re: And this is why I prefer OpenBSD's approach to Disk Encryption

        If you have proper folder redirection and a proper backup regimen, then access to the files on the individual machine is unnecessary. If your company depends on being able to access files on user systems, then your company is doomed. My company uses rsync over SSH to backup users' home directories and configuration deltas (EG pulling the logs from the package manager and producing diff's between the current version of a config file and the base file that shipped with the system).

        This happens daily and allows for backing up no matter where the employee is located so long as they are connected to the internet. The intention is that any lost / stolen / failed / attacked / infected system can just be fully written off and replaced with a new system with only trivial loss in productivity. Rather than waste time to disinfect systems or to try and recover files from a failed hard disk, we just grab a new machine, through an image on it, provide the list of packages that were on the system to the package manager to install, then apply all the backed-up diffs to the configuration files. The users' home directory is then copied onto the machine, rebooted and the user can carry on with, at most, loss of anything that happened in the last 24 hours.

  10. Anonymous Coward
    Anonymous Coward

    What bug?

    This is not a bug its a feature, and is fully approved by the UK government.

    War is Peace, Ignorance is Strength, Freedom is Slavery.

    Warm regards,

    Theresa May.

    1. Loyal Commenter Silver badge

      Re: What bug?

      We are at war with EurasiaEurope, we have always been at war with EurasiaEurope.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like