4 ms·

It's a very impressive exploit. But I wonder if the PoC||GTFO maxim for security researchers leads to a lot of wasted effort. I was convinced that ssh-agent ne

by tlb 3y ago

It's a very impressive exploit. But I wonder if the PoC||GTFO maxim for security researchers leads to a lot of wasted effort. I was convinced that ssh-agent needed fixing as soon as they pointed out that it (a) accepts the name of a shared library within /usr/lib to dlopen over the network and (b) the range of crazy things that standard shared libraries do. Did they need to do all the extra work of developing an exploit in order to convince someone that was dangerous?

tptacek 3y ago
That's a great question. I think the answer is: no. They probably agree. I think, like, 80% of this is just art. There's a notion of fleshing out the constructor/destructor attack surface, which someone on Mastodon pointed out was pretty similar to how deserialization exploits work (they're chains of classes you can only instantiate and not directly invoke methods on), but this might be the only time this particular variety of attack ever happens again. It's funny reading this thread full of people saying the attack is not that big a deal. It's a really big deal! It's just not a big deal for the reason people assume vulnerabilities are a big deal. :)
funcDropShadow 3y ago
> Did they need to do all the extra work of developing an exploit in order to convince someone that was dangerous? It might be clear in this case for someone who has already seen that really obscure bugs could be practically misused. But in the long-term, it is necessary to show that this is not some theoretical risk, which could be exploited in one never-heard-of hobby linux distribution. If security researchers skip these PoCs, a generation of future developers - who never saw practical PoCs - will just not believe it is relevant. Saying the security researchers don't need to show PoCs is like saying mathematicians don't need proof, they just need to be very sure that a theorem holds. That is the difference between a researcher/scientist and an engineer. An engineer could say, well this is likely exploitable, therefore let's safeguard against this. So that there remains a margin of security.
tialaramex 3y ago
My guess is that without the PoC you will too often run into somebody who insists that in practice it's fine. Not always, but maybe it's one time in five. And now you've been told it's "fine" and so you should meekly go away right? As I understand it that TOCTOU race in Rust's std::fs::remove_dir_all had been reported once before and just not accepted as a security bug. The C++ libraries have the excuse that WG21 decided this is all UB anyway and so they weren't required to fix the equivalent bug in their standard library, but in Rust the answer is that sometimes when you raise a real concern somebody says it's fine, erroneously. It's not like OpenSSH did this by accident. They did this on purpose and they apparently thought it was reasonable when they did it, so if it's supposedly obvious that it's a problem, why is it in the design?

by tlb 3y ago

tptacek 3y ago

That's a great question. I think the answer is: no. They probably agree. I think, like, 80% of this is just art. There's a notion of fleshing out the constructor/destructor attack surface, which someone on Mastodon pointed out was pretty similar to how deserialization exploits work (they're chains of classes you can only instantiate and not directly invoke methods on), but this might be the only time this particular variety of attack ever happens again. It's funny reading this thread full of people saying the attack is not that big a deal. It's a really big deal! It's just not a big deal for the reason people assume vulnerabilities are a big deal. :)

funcDropShadow 3y ago

> Did they need to do all the extra work of developing an exploit in order to convince someone that was dangerous? It might be clear in this case for someone who has already seen that really obscure bugs could be practically misused. But in the long-term, it is necessary to show that this is not some theoretical risk, which could be exploited in one never-heard-of hobby linux distribution. If security researchers skip these PoCs, a generation of future developers - who never saw practical PoCs - will just not believe it is relevant. Saying the security researchers don't need to show PoCs is like saying mathematicians don't need proof, they just need to be very sure that a theorem holds. That is the difference between a researcher/scientist and an engineer. An engineer could say, well this is likely exploitable, therefore let's safeguard against this. So that there remains a margin of security.

tialaramex 3y ago

My guess is that without the PoC you will too often run into somebody who insists that in practice it's fine. Not always, but maybe it's one time in five. And now you've been told it's "fine" and so you should meekly go away right? As I understand it that TOCTOU race in Rust's std::fs::remove_dir_all had been reported once before and just not accepted as a security bug. The C++ libraries have the excuse that WG21 decided this is all UB anyway and so they weren't required to fix the equivalent bug in their standard library, but in Rust the answer is that sometimes when you raise a real concern somebody says it's fine, erroneously. It's not like OpenSSH did this by accident. They did this on purpose and they apparently thought it was reasonable when they did it, so if it's supposedly obvious that it's a problem, why is it in the design?