4 ms·

the point isn't to get it to work without secure boot enabled, it's to have the benefits of secure boot as well as your own choice of OS. there's no reason to h

the point isn't to get it to work without secure boot enabled, it's to have the benefits of secure boot as well as your own choice of OS. there's no reason to have to compromise on security now like you did.

windsurfer 14y ago
If someone can just turn off secure boot, how does secure boot increase security? Isn't the whole point of it that you can't boot a compromised machine?
- etherealG 14y ago
  nope, the point is that the machine won't boot a compromised OS without the user knowing. the scenario is that the bootloader is compromised by some process other than the user turning it off. we're not trying to protect computers from the people that own them. security isn't about stopping people from having full control of their devices, it's about stopping processes from having control that the owners don't allow.
  - jebblue 14y ago
    >> it's about stopping processes from having control that the owners don't allow That's why I run Linux in the first place.
- recoiledsnake 14y ago
  To be certified for Windows 8, the device needs to support UEFI secure boot and allow a _physically present user_ to turn it off(typically in order to boot other OSes). It does reduce security a bit, but enhances user freedom a lot.
  - laumars 14y ago
    > It does reduce security a bit, but enhances user freedom a lot. "enhances" or "reduces" user freedom. There's nothing about secure boot that enhances freedom.
    - recoiledsnake 14y ago
      I was referring to the setting to turn Secure Boot off there, not Secure Boot itself.
laumars 14y ago
Secure boot doesn't offer any practical security. Most attacks are just social engineering, spyware and daemons for DDoS attacking. Basically all stuff that can be run from user space. There's no real advantage in writing rootkits in our current climate as it's significantly more complicated and not nearly as profitable. The cynical side of me thinks secure booting was intentionally developed to lock users into their respective platforms and only later sold as a security mechanism to avoid a massive outcry (a la the "terrorism" excuses that Apple used to argue against jailbreaking).
- recoiledsnake 14y ago
  The problem is that the social engineering, spyware and daemons can be(and are) turned into undetectable bootkits. I am tired of pasting the below text every time, but here we go again: http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i... http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_... http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft http://www.computerworld.com/s/article/9217953/Rootkit_infec... I recommend reading atleast the first link. Here's one juicy bit: TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled. When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper. The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting. The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data. The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components. TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files. All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection. Another bit: The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.
sliverstorm 14y ago
the point isn't to get it to work without secure boot enabled, it's to have the benefits of secure boot as well as your own choice of OS. Moving goalposts at their finest.

windsurfer 14y ago

If someone can just turn off secure boot, how does secure boot increase security? Isn't the whole point of it that you can't boot a compromised machine?

etherealG 14y ago
nope, the point is that the machine won't boot a compromised OS without the user knowing. the scenario is that the bootloader is compromised by some process other than the user turning it off. we're not trying to protect computers from the people that own them. security isn't about stopping people from having full control of their devices, it's about stopping processes from having control that the owners don't allow.
- jebblue 14y ago
  >> it's about stopping processes from having control that the owners don't allow That's why I run Linux in the first place.
recoiledsnake 14y ago
To be certified for Windows 8, the device needs to support UEFI secure boot and allow a _physically present user_ to turn it off(typically in order to boot other OSes). It does reduce security a bit, but enhances user freedom a lot.
- laumars 14y ago
  > It does reduce security a bit, but enhances user freedom a lot. "enhances" or "reduces" user freedom. There's nothing about secure boot that enhances freedom.
  - recoiledsnake 14y ago
    I was referring to the setting to turn Secure Boot off there, not Secure Boot itself.

laumars 14y ago

Secure boot doesn't offer any practical security. Most attacks are just social engineering, spyware and daemons for DDoS attacking. Basically all stuff that can be run from user space. There's no real advantage in writing rootkits in our current climate as it's significantly more complicated and not nearly as profitable. The cynical side of me thinks secure booting was intentionally developed to lock users into their respective platforms and only later sold as a security mechanism to avoid a massive outcry (a la the "terrorism" excuses that Apple used to argue against jailbreaking).

recoiledsnake 14y ago
The problem is that the social engineering, spyware and daemons can be(and are) turned into undetectable bootkits. I am tired of pasting the below text every time, but here we go again: http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i... http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_... http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft http://www.computerworld.com/s/article/9217953/Rootkit_infec... I recommend reading atleast the first link. Here's one juicy bit: TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled. When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper. The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting. The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data. The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components. TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files. All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection. Another bit: The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.

sliverstorm 14y ago

the point isn't to get it to work without secure boot enabled, it's to have the benefits of secure boot as well as your own choice of OS. Moving goalposts at their finest.