6 ms·

> This meant that by sending a ResponseKey message with an AES-encrypted <encoded> element of more than 1024 bytes, it was possible to overflow a heap buffer.

• UncleMeat 5y ago
  Yup. I wouldn't hate it if it were illegal to write new applications that processed untrusted input in memory-unsafe languages, at least in the not too distant future. The fact that the industry doesn't see this as an urgent need is just embarrassing.
  • junon 5y ago
    Imagine thinking we should, literally, police language.
    • UncleMeat 5y ago
      Imagine thinking we should, literally, police engineering techniques. If you build a bridge then you are expected to use techniques and systems that provide at least some degree of planned safety for the users of that bridge. It is virtually impossible to write a C++ program of any meaningful complexity that processes untrusted data in an unsandboxed environment that does not expose the owner of the device running that program to harm. To say otherwise is to ignore decades of observation. Every single person who starts writing a new application in a memory-unsafe language that will deal with untrusted inputs is declaring up front that they are willing to tolerate the inevitable vulnerabilities and exploits caused by that decision. I think it is very important that our industry develops a path to getting all such programs off of unsafe languages, since it is very clear that techniques like testing, fuzzing, and audits are not sufficient to actually produce safe programs.
      • virtue3 5y ago
        I initially disagreed with your viewpoint and after reading your response you've actually changed my mind. My only real gripe is I would prefer it came from the IEEE or something and not really from some government agency; or worse -> oracle or someone trying to get everyone to use java/their stuff.
        • UncleMeat 5y ago
          I personally don't think that the IEEE would have any capability of really shifting the industry. It isn't like IEEE guidance for privacy preserving programs really moved the needle. You needed legislation like GDPR to do that (and even then it remains incomplete). Ultimately, adopting memory-safe languages for systems programming is going to be very expensive. You need more than just recommendations to make that happen. I do think there is risk with legislation binding developers too much or forcing them into suboptimal approaches if things aren't written well. One could imagine legislation that does not permit the use of Rust because of the presence of `unsafe`, but that would be a terrible misstep.
      • bagels 5y ago
        I don't think comparing software to buildings is always apt. If a building collapses, it's likely that people will die. The consequences of failing software can be mere annoyances depending on the context of its use. Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care). I think one could come up with all sorts of analogies that fit or don't fit, such as, applying a similar argument to door locks. Why should it be legal to use ordinary keyed locks on houses when they are so easy to circumvent with basic lockpicks?
        • UncleMeat 5y ago
          Programs written in memory-unsafe languages are riddled with RCE vulns. This is true even for software written by companies that hire the very best security engineers in the world. The consequences of such software that processes untrusted input is more than mere annoyance. This sort of behavior is the root of RATs operated by both criminals and oppressive states. It does not matter if your program is intended for something as seemingly non-critical as text messaging - it will still be used to cause terrible harm. I do not think that the lock is a reasonable comparison here, because exploitation of software scales so so so much more effectively than picking locks. One exploit easily scales to millions of devices. So the harm caused by vulnerable software has a much higher ceiling than the harm caused by a weak lock.
    • staticassertion 5y ago
      We have quality and standards regulations for all sorts of things, thankfully. That software doesn't makes it the odd one out.
  • userbinator 5y ago
    That's the last thing I want to hear from the authoritarian industry who also writes user-hostile software, embraces DRM, and is deathly scared of users having control over their general-purpose computers. Insecurity is freedom. (Don't believe me? How is jailbreaking and rooting accomplished?)
    • UncleMeat 5y ago
      I do not believe it is remotely reasonable to say that our software should be deliberately insecure so that people have the ability to root their own devices. That problem can be solved with other means, without exposing all of our devices to anybody else in the world who can send the same payload. If I can root my device through an exploit then I am not at the mercy of the company that made the device. But I am now at the mercy of every single criminal or oppressive state that wants to use that exploit to harm me. And given that there is no way to confidently determine which pieces of software do not expose this capability, this cannot be an informed decision made by consumers.
      • userbinator 5y ago
        That problem can be solved with other means That's what they always say --- so how about solving that problem first, before thrusting ourselves head-first into advocating for full authoritarianism? But I am now at the mercy of every single criminal or oppressive state that wants to use that exploit to harm me. Good. That means power is not centralised. You can defend yourself instead. Besides, do you really want to be "at the mercy of the company that made the device" ? As we have seen multiple times, they do not really act in your interest. There's also plenty of dystopian sci-fi to show us what attempts at making a "perfect" society in any way will turn out. This applies to making software "perfectly secure" too.
        • UncleMeat 5y ago
          > That's what they always say --- so how about solving that problem first, before thrusting ourselves head-first into advocating for full authoritarianism? Expecting more secure applications is "advocating for full authoritarianism"? If anything, security vulnerabilities place individuals at far greater risk to authoritarianism since it exposes them to the people who have guns and can throw them in prison. And software written in memory-safe languages is very very far from "perfectly secure". It just closes a very common class of vulnerability. If you really want, you can use FLOSS for everything. Your use case of "I really want the ability to change any piece of code running on my device" is supported. Not well, since few people actually want this, but it is supported.
• dvt 5y ago
  > We gotta get off memory-unsafe languages. You read this whole post and that's what you got? Just the fact that this includes a heap grooming step should be pretty telling that it's not very reliable and that it can easily be broken (it probably won't work if you try it after the next Win10 update). I mean, yeah, sure, buffer overflows are bad, but this is an extremely sophisticated attack that relies on like a zillion moving pieces, of which "memory-unsafe languages" are basically a footnote. Props to the dedication and expertise of the security researchers.
  • asdfasgasdgasdg 5y ago
    Would the exploit have been possible without this, though? Possibly but it would have been that much harder to accomplish. I think it's a fair if overdone observation that C is a bad language to use if you want to minimize the incidence of RCEs.
  • feanaro 5y ago
    Why does it matter how reliable it is? What matters is that it's possible. If it breaks with an update, the technique can be pretty easily adapted to work again.
  • staticassertion 5y ago
    Just because there's heap grooming involved doesn't mean it's unreliable. Exploits that use heap grooming can often be ~100% reliable. Our POC for Sigred required lots of heap grooming but it was extremely reliable. https://www.graplsecurity.com/post/anatomy-of-an-exploit-rce-with-cve-2020-1350-sigred https://www.graplsecurity.com/post/anatomy-of-an-exploit-rce... The overflow was hardly a footnote either, it's the primary bug being exploited here.
    • staticassertion 5y ago
      FWIW, and this is not a 'dis' at the researchers, I would also not say this is "extremely sophisticated". Most attacks these days involve chaining lots of bugs like this and using grooming techniques. It's extremely impressive work and I have great respect for people who can do that, but I would reserve "extremely sophisticated" for cases where novel techniques are used, which isn't really the case here.
• Popegaf 5y ago
  That's going to take a while. But at least the linux kernel is starting to integrate Rust. It's doubtful they'll rewrite the whole thing in Rust, but getting it in there is a start. I know the Chromium team was considering switching to Rust too, but who knows if that's ever going to happen. IIRC Chromium has more LOC than the linux kernel.
  • steveklabnik 5y ago
    There is a PR (or whatever they call them) to add the rust toolchain into chromium’s build infrastructure. The link is in my submission history. Didn’t get any traction on here, but fingers crossed!