4 ms·

> Web engines are full of security vulnerabilities, like buffer overflows, null pointer dereferences, and use-after-frees. Off-topic to the issue at hand, but

> Web engines are full of security vulnerabilities, like buffer overflows, null pointer dereferences, and use-after-frees. Off-topic to the issue at hand, but I am curious: would Servo[1], the browser engine written in Rust be having lesser (chances of) issues like this? I have written very little Rust, but it seems that the above issues are extremely unlikely to occur with Rust. [1]: https://servo.org/ https://servo.org/

neikos 11y ago
Unless they mis-use `unsafe` the chances are very low and would be in the compiler rather than the source code. So yes, those errors should not appear. Others are still possible and might be just as bad.
notalaser 11y ago
Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper. I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after-frees, but the OpenGL bindings that it calls through the FFI aren't. To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.
- orf 11y ago
  > and languages like Rust don't make it less likely to err It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.
  - notalaser 11y ago
    It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against. Not to mention errors stemming from our own arrogance and short-sightedness, which no language can ever protect us against.
    - mikeash 11y ago
      If it makes it less likely that some errors get out, and doesn't do anything against other errors, then overall it makes it less likely that errors get out.
      - notalaser 11y ago
        What makes you think that it does not introduce any additional errors?
        mikeash 11y ago
        What makes you think that it does?
        notalaser 11y ago
        The course of programming so far.
        pcwalton 11y ago
        Please tell me how Rust introduces more possibilities for remote code execution vulnerabilities (the most severe). We're not talking about errors as a whole here. The only RCE classes unique to memory-safe languages that come to mind are, like, dynamic deserialization vulnerabilities (like the Rails one) and remote includes (like PHP). Neither of these are applicable to Rust.
      - barkingcat 11y ago
        errors are not zero-sum. There's no finite pool of error that we're whittling down - there will likely be new error types we didn't know about or introduced by the new code.
- pcwalton 11y ago
  > To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. That's completely false as stated. Memory safety vulnerabilities are far, far less common in Python (say) than Java. You may have seen buffer overflows in Java, but they're extremely rare in comparison. You're falling to the "black and white security" fallacy: the belief that if you can't solve a security problem 100% it's not worth solving it at all. In reality, a 99% solution is extremely valuable and in fact almost always the best you can do. > Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is. That's very philosophical, but go look at the list of vulnerabilities. Count how many are straightforward memory safety problems: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html It's the vast majority, of course. Memory safe languages don't eliminate all security vulnerabilities. But they do reduce their quantity dramatically.
hannob 11y ago
Well, chances are that Servo will have much fewer bugs than today's browser engines. The approach of Servo and Rust is to design in a way that certain classes of bugs are eliminated by default. Only time will tell how good this will work, but I'm hopeful. That would mean you have a smaller problem. Fewer vulns, fewer reasons to have security updates. But it's unlikely that Servo will have no vulns at all. There are classes of bugs (e.g. logic vulns) that are unlikely to have any "generic" strategy to beat them. So you still need a working process to deliver security fixes to the user.
- FreeFull 11y ago
  Servo also uses the SpiderMonkey engine for Javascript, which is written in C++, although also is hopefully battle-tested enough that there aren't too many bugs in it.
discreditable 11y ago
No software is bug-free. The problem here is distribution. If clients were using Servo instead of WebKit, they'd still be stuck on old insecure and/or buggy versions.
- pcwalton 11y ago
  Very true. However, the number of remote code execution vulnerabilities resulting from memory safety problems would be lower. This matters because these comprise the vast majority of vulnerabilities on the list.

neikos 11y ago

Unless they mis-use `unsafe` the chances are very low and would be in the compiler rather than the source code. So yes, those errors should not appear. Others are still possible and might be just as bad.

notalaser 11y ago

Never underestimate what misguided cleverness can do. Heartbleed, the most famous of these issues in the last few years, would have not occurred on systems like OpenBSD, were it not for its developers' quest for optimization in their malloc wrapper. I've seen buffer overflows in Java, too. It's immune to writing past the end of the arrays, but it's not immune to, say, smart programmers using one large array to hold multiple buffers that they manually manage, because who knows when the GC kicks in and wrecks havoc. Python may be immune to use-after-frees, but the OpenGL bindings that it calls through the FFI aren't. To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is.

orf 11y ago
> and languages like Rust don't make it less likely to err It doesn't make the person less likely to err overall, but it makes it less likely that those errors get compiled and released.
- notalaser 11y ago
  It makes it less likely that those errors that we're familiar with from C get compiled and released. There's no debate there. It's all those errors that we're not familiar with from C that it won't do anything against. Not to mention errors stemming from our own arrogance and short-sightedness, which no language can ever protect us against.
  - mikeash 11y ago
    If it makes it less likely that some errors get out, and doesn't do anything against other errors, then overall it makes it less likely that errors get out.
    - notalaser 11y ago
      What makes you think that it does not introduce any additional errors?
      - mikeash 11y ago
        What makes you think that it does?
        notalaser 11y ago
        The course of programming so far.
      - pcwalton 11y ago
        Please tell me how Rust introduces more possibilities for remote code execution vulnerabilities (the most severe). We're not talking about errors as a whole here. The only RCE classes unique to memory-safe languages that come to mind are, like, dynamic deserialization vulnerabilities (like the Rails one) and remote includes (like PHP). Neither of these are applicable to Rust.
    - barkingcat 11y ago
      errors are not zero-sum. There's no finite pool of error that we're whittling down - there will likely be new error types we didn't know about or introduced by the new code.
pcwalton 11y ago
> To err is human, and languages like Rust don't make it less likely to err, they just give you new opportunities to do it. That's completely false as stated. Memory safety vulnerabilities are far, far less common in Python (say) than Java. You may have seen buffer overflows in Java, but they're extremely rare in comparison. You're falling to the "black and white security" fallacy: the belief that if you can't solve a security problem 100% it's not worth solving it at all. In reality, a 99% solution is extremely valuable and in fact almost always the best you can do. > Moving to a safe language like Rust would help, absolutely, but to a far lesser degree than people hope. It would close far fewer cans of worms than the hive mind hopes, and it's so new no one really knows how big its own can of worms is. That's very philosophical, but go look at the list of vulnerabilities. Count how many are straightforward memory safety problems: http://webkitgtk.org/security/WSA-2015-0002.html http://webkitgtk.org/security/WSA-2015-0002.html It's the vast majority, of course. Memory safe languages don't eliminate all security vulnerabilities. But they do reduce their quantity dramatically.

hannob 11y ago

Well, chances are that Servo will have much fewer bugs than today's browser engines. The approach of Servo and Rust is to design in a way that certain classes of bugs are eliminated by default. Only time will tell how good this will work, but I'm hopeful. That would mean you have a smaller problem. Fewer vulns, fewer reasons to have security updates. But it's unlikely that Servo will have no vulns at all. There are classes of bugs (e.g. logic vulns) that are unlikely to have any "generic" strategy to beat them. So you still need a working process to deliver security fixes to the user.

FreeFull 11y ago
Servo also uses the SpiderMonkey engine for Javascript, which is written in C++, although also is hopefully battle-tested enough that there aren't too many bugs in it.

discreditable 11y ago

No software is bug-free. The problem here is distribution. If clients were using Servo instead of WebKit, they'd still be stuck on old insecure and/or buggy versions.

pcwalton 11y ago
Very true. However, the number of remote code execution vulnerabilities resulting from memory safety problems would be lower. This matters because these comprise the vast majority of vulnerabilities on the list.