4 ms·

I have to say this is definitely a bug and I'm glad it's fixed ... but what kind of psycho boots their machine from an untrusted host? If the attacker controls

I have to say this is definitely a bug and I'm glad it's fixed ... but what kind of psycho boots their machine from an untrusted host? If the attacker controls the http service tightly enough to send malicious headers, avoiding this overflow is the least of your problems, since they have compromised your certs and also can just send a compliant payload with more malware on it. Bug? absolutely. Critical? not so sure.

deleted 3y ago
[deleted]
hackernudes 3y ago
Perhaps it could be used to break in to some locked devices.
deleted 3y ago
[deleted]
TheSoftwareGuy 3y ago
The only good form of defense, is defense in depth, or forming layers of defense. This bug puts a hole in one of those layers
- JackSlateur 3y ago
  Well, yes, but actually, no
AshamedCaptain 3y ago
The same kinds of psycho who promote Secure Boot. They _really_ believe in a security strategy which _requires_ everything that could be potentially be compromised to not be signed by Secure Boot. The moment you have something signed which has a vulnerability, you can use it to decrypt everyone's SecureBoot+TPM encrypted hard drives. Why that ever was considered a valid security approach is over me, as there is an entire gallery of vulnerabilities like this one. It also completely ignores the elephant in the room called Windows. Example of this type of thinking: https://lkml.org/lkml/2018/4/3/767 https://lkml.org/lkml/2018/4/3/767 Note that despite Linus' reticences, in a lot of distros integrity mode is indeed enabled when you boot with Secure Boot on. Likely because of MS politics and distros wanting an MS UEFI signature being forced to "go through the hoops" as explained in that thread. As a result enabling Secure Boot usually cripples your distro, preventing you from e.g. hibernating.
stonogo 3y ago
replying to myself to point out an excellent explanation in another thread: https://news.ycombinator.com/item?id=39135275 https://news.ycombinator.com/item?id=39135275 in sum, it's critical, because the attack vector is beyond just http.

deleted 3y ago

[deleted]

hackernudes 3y ago

Perhaps it could be used to break in to some locked devices.

deleted 3y ago

[deleted]

TheSoftwareGuy 3y ago

The only good form of defense, is defense in depth, or forming layers of defense. This bug puts a hole in one of those layers

JackSlateur 3y ago
Well, yes, but actually, no

AshamedCaptain 3y ago

The same kinds of psycho who promote Secure Boot. They _really_ believe in a security strategy which _requires_ everything that could be potentially be compromised to not be signed by Secure Boot. The moment you have something signed which has a vulnerability, you can use it to decrypt everyone's SecureBoot+TPM encrypted hard drives. Why that ever was considered a valid security approach is over me, as there is an entire gallery of vulnerabilities like this one. It also completely ignores the elephant in the room called Windows. Example of this type of thinking: https://lkml.org/lkml/2018/4/3/767 https://lkml.org/lkml/2018/4/3/767 Note that despite Linus' reticences, in a lot of distros integrity mode is indeed enabled when you boot with Secure Boot on. Likely because of MS politics and distros wanting an MS UEFI signature being forced to "go through the hoops" as explained in that thread. As a result enabling Secure Boot usually cripples your distro, preventing you from e.g. hibernating.

stonogo 3y ago

replying to myself to point out an excellent explanation in another thread: https://news.ycombinator.com/item?id=39135275 https://news.ycombinator.com/item?id=39135275 in sum, it's critical, because the attack vector is beyond just http.