3 ms·
If a system is designed to not allow that access, and you can compromise that design, it is most definitely a vulnerability.
by bdcravens 4y ago
If a system is designed to not allow that access, and you can compromise that design, it is most definitely a vulnerability.
- nine_k 4y agoIf a system is not resilient against rooting a terminal which is in user's physical possession, it's a design flaw. Or, rather, the more resilient the system as a whole is to compromises of individual terminals, the better the design is. Assuming such compromise never happens would be outright incompetent.
- mlyle 4y agoYou might very well want both E.g. You may want to protect end users against implants and other attacks from physical tampering with their terminals. You might not want hostile parties to have an easy time reverse engineering terminals so they can more easily search for remote vulnerabilities in the terminals. You may not want to hand hostile parties a phased array optimized to transmit to Starlink running arbitrary software of their choice, along with keys identifying the terminal, because even though you think the satellites and authentication mechanisms are robust, making it hard to get this information adds defense in depth.
- nine_k 4y agoCertainly. Best defence is layered. It makes every layer an impediment for an attacker, but does not fail completely if a layer or two is breached. Among other things, it buys time to react.
- Denvercoder9 4y agoI'm convinced that it's impossible to prevent anyone that can physically tamper with a system from having full privileges on that system, as a result of physics. The only way to truly protect information is to make use of quantum effects, and we've only just started doing that in labs. Everything else is just making it harder. So, if you make things harder and someone comes along that invests more effort to overcome, can you really call that a vulnerability? It'd be a real vulnerability if with this access to a user terminal they could elevate permissions on the satellites, but that hasn't been shown (yet?).
- akira2501 4y ago> can you really call that a vulnerability? Yes. Just because executing the attack doesn't seem to get you anything particularly valuable doesn't make it "not a vulnerability." We're not personally insulting it, we're just describing reality.
- xaduha 4y ago> Everything else is just making it harder. If it's hard enough that only state actors can potentially do it, then what does it matter in real life that it's theoretically vulnerable?
- czx4f4bd 4y agoYes. Vulnerabilities exist with respect to a system's expected functionality and must be understood and weighed against other requirements to determine the system's security model. Even if you think the expected functionality is stupid or impossible, that doesn't change the fact that the system has a particular expectation that it doesn't meet and a mechanism by which that expectation can be violated, i.e. a vulnerability. To put it another way, consider physical locks, which must inherently be able to resist direct physical tampering by an adversary. Under your definition, no flaw in a lock could be considered a vulnerability since any lock can eventually be cracked. The problem is that this doesn't provide us any useful insight, it just makes the word "vulnerability" useless. It's already well-known that any lock can eventually be cracked, but tradeoffs still have to be made in deciding which lock to use for a certain situation.
- josephcsible 4y agoNo lock is expected to be able to keep an adversary out indefinitely, since that's known to be completely impossible. They're expected to delay an adversary by a given amount of time, e.g., 2 hours for a UL class 3 vault door lock, and a vulnerability is if there's a way for an adversary to bypass one faster than that. The problem with a security model that relies on people never being able to root devices they possess is that it is expecting the impossible.
- bri3d 4y ago