91–100 of 154 posts
Fuck 'em.
> Second is cell carriers are not wild about unknown basebands conversing with their networks.
Fuck 'em.
> In theory the network should defend against bad phones but they'd rather not test that.
... hard.
Earlier quoted context omitted.
I think this exploit requires local administrative access. If an attacker already has this, you're pretty screwed to begin with. In other words, while this could definitely make an attack more damaging and harder to remove, it doesn't seem like a reason to stop using a computer that has decent software and physical security.
This exploit just requires physical, not administrative, access to the machine. You build an EFI "app", put it on a flash drive, and execute it from the UEFI shell.
I wish we could even purchase machines without SMM, Intel Management Engine, and similar features. On any machine I own, I want the CPU and the software running in ring zero to be the last word on what happens. I don't think it's unreasonable to ask for a system that meets this requirement.
I think you were there during the Win8 period when UEFI secure boot and ACPI BGRT was introduced for example, right?
Earlier quoted context omitted.
Although you are correct, I don't feel it's bad to blame the vendor who was running code that they didn't know the source of, nor the reasoning behind it's existence.
So, literally every vendor? Can you think of a single example of a vendor not running UEFI code from others, not running either Qualcomm's kernels for ARM chips, nor distributing Intel's ME firmaware, nor distributing AMD's TPM firmware? I don't think there's a single OEM that knows what they're actually running – if there is, SAMSUNG would likely be it, because they have a chance at actually doing everything in-hous…
This should be good news for people looking to getting rid of Computrace, effectively a rootkit, from surplus Thinkpads. http://forum.thinkpads.com/viewtopic.php?t=114641 Yes, I bought a surplus Thinkpad (T61) and found it had Computrace activated on it. Grrrr. Yes, I could call the Absolute(R) Software number and they should disable it for me. I have not been willing to sit on hold and jump their hoops to date. Sinc…
Earlier quoted context omitted.
As I commented elsewhere, we can, see https://news.ycombinator.com/item?id=12037410
That's good to hear. Thanks!
Earlier quoted context omitted.
Although you are correct, I don't feel it's bad to blame the vendor who was running code that they didn't know the source of, nor the reasoning behind it's existence.
So, literally every vendor? Can you think of a single example of a vendor not running UEFI code from others, not running either Qualcomm's kernels for ARM chips, nor distributing Intel's ME firmaware, nor distributing AMD's TPM firmware? I don't think there's a single OEM that knows what they're actually running – if there is, SAMSUNG would likely be it, because they have a chance at actually doing everything in-hous…
I wish we could even purchase machines without SMM, Intel Management Engine, and similar features. On any machine I own, I want the CPU and the software running in ring zero to be the last word on what happens. I don't think it's unreasonable to ask for a system that meets this requirement.
As I commented elsewhere, we can, see https://news.ycombinator.com/item?id=12037410
Earlier quoted context omitted.
This exploit just requires physical, not administrative, access to the machine. You build an EFI "app", put it on a flash drive, and execute it from the UEFI shell.
Well, physical access ranks higher than administrative. If an attacker has physical access, no system is secure, if only because the interface to the system is no longer.
indeed countermeasure like full disk encryption, computrace and Mac firmware passwords are all examples of things we do to raise the difficulty for a physical attacker.