6 ms·

If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. "Oh, but the average user is incapable of th

If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. "Oh, but the average user is incapable of that" and "Corporate IT are unwilling to do that" are the two biggest excuses I hear to not make it so. Here's a crazy idea: you connect said jumper to a front panel key switch. The 'average' consumer could probably sort that out. And corporate IT could just leave it enabled, or require you to turn the key for them, or have IT interns on site that run around with the keys or whatever. A Key. A literal physical key. But I guess that's too low tech for the crypto obsessed purveyors of TPMs and the like.

2OEH8eoCRo0 5y ago
I don't understand this either. A physical presence requirement eliminates all remote threats. The vast majority of these attacks occur from the safety of some far away adversarial country. They'd have to have agents on the ground carrying out these attacks and getting caught.
snthd 5y ago
If you turn the key, how do you really know it's your firmware that's being written?
- greenbit 5y ago
  Point is, if you Don't turn the key, you sleep well at night knowing it's Not Being Written. Contrary to the apparent belief of the developers of New Products, a good many of us are sick to death of everything "as a service", and all the headaches that ensue.
  - AshamedCaptain 5y ago
    I am sure one of these "New Products" developers will come here and share the story of the Evil Hotel Maid that comes to your room and toggles the physical switch on your computing products.
    - rzwitserloot 5y ago
      Anybody that peddles you an absolute safety in IT security is an idiot who should be swiftly ignored. If they work for you, fired and all their work thoroughly reviewed. The flip side of that argument is just as true: Anybody that denigrates a security measure because they can come up with a single convoluted compromise is an idiot. I'm hoping that's not you, it sounds like you're saying that some hypothetical strawman developer would say such a thing (Sounds like a particularly plausible strawman to me... a sad state of affairs!) – but that's the defense if you meet such dangerous idiots. With this proposal, there's a key involved, which is some extremely limited defense against evil maids. If it's truly a key as in 'keys in doors', you can pick it, trivially (see Lockpicking Lawyer's video stream for how trivial it is to pick or otherwise circumvent locks). A well thought through system can fix many of these warts - in this case all you need is an unresettable flag that shows: Compromised! Designing a lock that can detect but not defend against picking is a lot easier than making an unpickable lock. But I'm sure LPL or somebody else with skills, experience, lots of time, and a budget to buy a bunch and open em up to look at how they work can come up with a scheme to pick em open without triggering the flag. You could also make it a digital key (or a combination even). Point is, pre-supposing a well-tested design with input from experts is mostly just begging the question: If I had that, we might as well posit 'Let us assume no bugs in any firmware implementations of stuff'. And for an encore, let's posit "world peace", about as useful. It's all swiss cheese: _EVERYTHING_ has holes. Nothing is perfect. But, layer enough slices of swiss cheese on a slice of bread and pretty soon no bread is visible. A physical key rather obviously covers precisely those holes that schemes involving entirely digital and remote-accessible setups have. Thus it is a great idea, and the fact that an evil maid can attack it indicates someone either doesn't understand the fundamentals of security (they don't get that it's all imperfect, and combining to cover the gaps is almost always the winning move), or is intentionally coming up with pithy oversimplified toss to cheerlead their product or pet preference.
mjg59 5y ago
Flash needs to be writable at runtime - things like ram training parameters are stored there.
- zbentley 5y ago
  Parameters could be stored in separate memory from the operating system that interprets those parameters. This is somewhat similar to what Apple does with the secure enclave. That way, wearout parameters and non-risky user tunables would still be customizable without risk of compromise. Heck, even if that had to be implemented with an entirely separate hardware chip for parameter storage on the motherboard, the added cost would be negligible.
axiolite 5y ago
> If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. This would make it incredibly hard to manage a bunch of servers in various remote data centers. > connect said jumper to a front panel key switch Ah yes, I do miss the good old days of front-panel key switches, where rubbing your feet and touching the front would reboot your system. I've never seen a smartphone or ultrabook with one, though.

2OEH8eoCRo0 5y ago

I don't understand this either. A physical presence requirement eliminates all remote threats. The vast majority of these attacks occur from the safety of some far away adversarial country. They'd have to have agents on the ground carrying out these attacks and getting caught.

snthd 5y ago

If you turn the key, how do you really know it's your firmware that's being written?

greenbit 5y ago
Point is, if you Don't turn the key, you sleep well at night knowing it's Not Being Written. Contrary to the apparent belief of the developers of New Products, a good many of us are sick to death of everything "as a service", and all the headaches that ensue.
- AshamedCaptain 5y ago
  I am sure one of these "New Products" developers will come here and share the story of the Evil Hotel Maid that comes to your room and toggles the physical switch on your computing products.
  - rzwitserloot 5y ago
    Anybody that peddles you an absolute safety in IT security is an idiot who should be swiftly ignored. If they work for you, fired and all their work thoroughly reviewed. The flip side of that argument is just as true: Anybody that denigrates a security measure because they can come up with a single convoluted compromise is an idiot. I'm hoping that's not you, it sounds like you're saying that some hypothetical strawman developer would say such a thing (Sounds like a particularly plausible strawman to me... a sad state of affairs!) – but that's the defense if you meet such dangerous idiots. With this proposal, there's a key involved, which is some extremely limited defense against evil maids. If it's truly a key as in 'keys in doors', you can pick it, trivially (see Lockpicking Lawyer's video stream for how trivial it is to pick or otherwise circumvent locks). A well thought through system can fix many of these warts - in this case all you need is an unresettable flag that shows: Compromised! Designing a lock that can detect but not defend against picking is a lot easier than making an unpickable lock. But I'm sure LPL or somebody else with skills, experience, lots of time, and a budget to buy a bunch and open em up to look at how they work can come up with a scheme to pick em open without triggering the flag. You could also make it a digital key (or a combination even). Point is, pre-supposing a well-tested design with input from experts is mostly just begging the question: If I had that, we might as well posit 'Let us assume no bugs in any firmware implementations of stuff'. And for an encore, let's posit "world peace", about as useful. It's all swiss cheese: _EVERYTHING_ has holes. Nothing is perfect. But, layer enough slices of swiss cheese on a slice of bread and pretty soon no bread is visible. A physical key rather obviously covers precisely those holes that schemes involving entirely digital and remote-accessible setups have. Thus it is a great idea, and the fact that an evil maid can attack it indicates someone either doesn't understand the fundamentals of security (they don't get that it's all imperfect, and combining to cover the gaps is almost always the winning move), or is intentionally coming up with pithy oversimplified toss to cheerlead their product or pet preference.

mjg59 5y ago

Flash needs to be writable at runtime - things like ram training parameters are stored there.

zbentley 5y ago
Parameters could be stored in separate memory from the operating system that interprets those parameters. This is somewhat similar to what Apple does with the secure enclave. That way, wearout parameters and non-risky user tunables would still be customizable without risk of compromise. Heck, even if that had to be implemented with an entirely separate hardware chip for parameter storage on the motherboard, the added cost would be negligible.

axiolite 5y ago

> If we just had flash that was write protected unless a jumper was moved, this kind of thing just would not happen. This would make it incredibly hard to manage a bunch of servers in various remote data centers. > connect said jumper to a front panel key switch Ah yes, I do miss the good old days of front-panel key switches, where rubbing your feet and touching the front would reboot your system. I've never seen a smartphone or ultrabook with one, though.