Announcement

Collapse
No announcement yet.

The State Of Linux Distributions Handling SecureBoot

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • crazycheese
    replied
    Originally posted by mjg59 View Post
    If they can write directly to your hard drive then they can inject kernel code by just replacing your kernel or bootloader and rebooting. That's the whole point.
    CRC missmatch on reboot. Or segfault. Or both.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by mjg59 View Post
    Again, please describe a solution that Microsoft could have used to prevent bootloader malware without also preventing booting of unsigned Linux. They worried about their OS. They came up with a solution that works for their OS. If you don't like their solution, describe a better one.
    I have pointed out the correct solution in the end of the post above.
    They are playing around with trust games, where they themselves trust only in own closed cycle society, but require others to trust them.
    This will never work, unless they lie and FUD.

    They just GPL the whole codebase and gain instant trust from everyone, that includes all cryptomechanisms.
    Then, they just sell copies with one-slot serial. I think ID invented it with Quake3....
    Still... they will go bankrupt in next 5 years. Because they exist only due to monopoly which will stop existing once they GPL the system.
    Because in this system only the top contributor gets money, not the top brawler.

    ----
    I will address whole three quotes seperately and then as one whole, because they line up forming a proof.
    Originally posted by mjg59 View Post
    That's what I said. You're free to sell a computer running Windows 8 without Secure Boot. You don't get the Microsoft certification. Since you're not forced to ship with Secure Boot enabled (merely given an incentive to), it's probably not an antitrust violation.
    No, the link pointed out that "You don't get the Microsoft certification" means "you quit freely our 'protection', meet you at your own funeral".

    Originally posted by mjg59 View Post
    The touch hardware needs to be certified, not the entire platform.
    No, the hardware case is not important. The important is the INCIDENT, which proves that uncertified systems (see above) can and will have reduced functionality, while paying SAME price.

    Originally posted by mjg59 View Post
    Absolutely, which is why Microsoft require that it be possible to replace the Microsoft keys on any x86 systems. Anyone with access to the firmware menu can install their own keys.
    And here it comes.

    No one will risk own extinction.

    No one will deactivate SecureBoot. At least, in living form on the market.

    You can't replace keys. Consider this crude code example:

    Code:
    if (microsoft_certified == true) goto work;
    
    die_due_to_high_costs_and_no_support_from_monopoly_owner(OEM_pointer);
    
    if (microsoft_certified == false) 
    printf("Freedom..Choice...Fairness... You replace keys here...");
    
    work:
    // (obfuscated code here)
    Last edited by crazycheese; 28 December 2012, 08:16 PM.

    Leave a comment:


  • mjg59
    replied
    Originally posted by crazycheese View Post
    First, they need to do that. That's what other layers are up to.
    Second, even if have done that, they only defeated one layer. They can't inject kernel code, only in userspace. And userspace can be CRCed as well - but thats outside even of SecureBoot scope.
    If they can write directly to your hard drive then they can inject kernel code by just replacing your kernel or bootloader and rebooting. That's the whole point.

    The difference is that my "version" does not require you to "surrender" to me or be executed.
    Your version requires everyone to have two computers if they want protection. It also requires every user to generate a key and store it on the other computer. It also means that they have to regenerate their signature every time they update the kernel or bootloader, and to do that they have to connect it to the other computer. It's user-hostile and unworkable.

    Don't take this as an absolute endorsement of Microsoft's approach. I'd prefer that a neutral third party be in charge of handling signatures. But nobody's been willing to spend the millions of dollars that would be required for that to happen, and so it hasn't.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by ShadowBane View Post
    Really, any of the remote root exploits listed here would allow the installation of bootloader viruses...
    Search Exploit Database for Exploits, Papers, and Shellcode. You can even search by CVE identifiers.


    Bootloader exploits are attractive because they are very hard to detect from a booted computer. There is no reason to expect that people using Linux would never be targeted by such attacks.
    Sure nice database of non-working exploits(hint: outdated) , very valuable for studying.

    Leave a comment:


  • mjg59
    replied
    Originally posted by duby229 View Post
    How many more times do I need to say this? How many different ways can it be said?

    THATS NOT OUR PROBLEM!!!

    If MS is so worried about their OS, then let them worry about their OS.
    Again, please describe a solution that Microsoft could have used to prevent bootloader malware without also preventing booting of unsigned Linux. They worried about their OS. They came up with a solution that works for their OS. If you don't like their solution, describe a better one.

    Leave a comment:


  • crazycheese
    replied
    Originally posted by mjg59 View Post
    Doesn't help. If someone's gained root access they can just modify /dev/sda directly.
    First, they need to do that. That's what other layers are up to.
    Second, even if have done that, they only defeated one layer. They can't inject kernel code, only in userspace. And userspace can be CRCed as well - but thats outside even of SecureBoot scope.

    Originally posted by mjg59 View Post
    That'd work, though you'd want to use a cryptographic signature instead of a CRC - it's easy to force a CRC to match. The easiest thing to do would be to have the firmware verify the signature, that way you don't need a second computer to verify your laptop every time you want to boot it.
    By "CRC" I meant "hash", not as particular hashing algorithm like CRC32 etc.
    It is possible to check by system hardware, if its prone to bugs, which it isn't. So its better to use independent system, connecting only for time of pre-boot checks as RO.

    Originally posted by mjg59 View Post
    And... you've just reinvented Secure Boot.
    There is minor difference and a small attribute that you are sure aware of.

    The difference is that my "version" does not require you to "surrender" to me or be executed.

    The small attribute is that my "version" was "invented" in 10 seconds of time, and I sure have read about it 2-3 years ago on the network. That means, it is already used in production.

    And also, if case anyone with ideas browsing, the whole idea above is Defensive Publication at date/time of original post.
    So don't even try.
    Last edited by crazycheese; 28 December 2012, 07:52 PM.

    Leave a comment:


  • mjg59
    replied
    Originally posted by duby229 View Post
    Getting root access on linux is horribly difficult to do without the password. If you dont believe me then try it for yourself.
    Yeah, it's horribly difficult to modify your .bashrc to alias sudo to something that steals your password. But honestly? I'm a kernel developer. I work on security-related topics. I have a pretty solid idea of how frequently new exploits are found that permit code to be executed as root even without tricking you into handing over your password.

    Leave a comment:


  • duby229
    replied
    Originally posted by dashcloud View Post
    I don't like to say this to people, but you are an idiot. How do you know what a boot virus looks like? You can certainly detect all the current known ones, but how do you defend against future ones and variants of current ones? Do you provide updates? If so, how do the updates get done?
    If you go down this path, you've re-invented the modern virus scanner- only worse, as you probably have to put this in a chip, not on a disk, and come up with a way to safely & securely update it. Definition-based virus scanners are great at detecting current and old viruses, but not near-future, and tomorrow's viruses/etc.

    The problem is if you can install any operating system on the machine, you can subvert any operating system on the machine.
    How many more times do I need to say this? How many different ways can it be said?

    THATS NOT OUR PROBLEM!!!

    If MS is so worried about their OS, then let them worry about their OS.

    EDIT: sometimes you gotta do what you gotta do. The thing about freedom is that you're frre to do whatever you want to do as long as you're not stepping on somebody elses freedoms...

    EDIT2: And about subverting an OS... That will always be true. Secureboot is not going change that. MS OSes have been by far the worst offenders. Windows 8 is -not- going to be exception. It will get infected just as badly as the rest of them have. Secureboot wont fix that. The only thing it does is give MS the ability to decide what OSes are acceptable to boot and which ones arent. THAT is NOT their place. What they need to do is ban the worst offenders... But that would fuck themselves.
    Last edited by duby229; 28 December 2012, 08:06 PM.

    Leave a comment:


  • duby229
    replied
    Originally posted by ShadowBane View Post
    Really, any of the remote root exploits listed here would allow the installation of bootloader viruses...
    Search Exploit Database for Exploits, Papers, and Shellcode. You can even search by CVE identifiers.


    Bootloader exploits are attractive because they are very hard to detect from a booted computer. There is no reason to expect that people using Linux would never be targeted by such attacks.
    OK so then lets come up with a native solution. We damn sure dont need MS to decide that since linux can get a boot virus we should just prevent it from booting. I'll promise you that windows can get a boot virus. So lets just prevent -IT- from booting.

    But see that's my point... MS does --NOT-- need to worry about whether or not linux can get targeted by such attacks... It isnt their concern at all. Not even a teeny weeny tiny little bit.

    EDIT: MS can come up with whatever excuses they want, but they will never be able to come up with enough excuses to give them the right to determine what linux is acceptable to boot from.
    Last edited by duby229; 28 December 2012, 07:56 PM.

    Leave a comment:


  • dashcloud
    replied
    Originally posted by duby229 View Post
    If you boot Windows 8, You must use secureboot. How is that not forced?

    If it really was a mechanism to protect against boot viruses.... Shouldnt it look for boot viruses?
    I don't like to say this to people, but you are an idiot. How do you know what a boot virus looks like? You can certainly detect all the current known ones, but how do you defend against future ones and variants of current ones? Do you provide updates? If so, how do the updates get done?
    If you go down this path, you've re-invented the modern virus scanner- only worse, as you probably have to put this in a chip, not on a disk, and come up with a way to safely & securely update it. Definition-based virus scanners are great at detecting current and old viruses, but not near-future, and tomorrow's viruses/etc.

    The problem is if you can install any operating system on the machine, you can subvert any operating system on the machine.

    Leave a comment:

Working...
X