3 ms·

Sandboxes and, to a certain extend, containers, are mitigation techniques ! Since you cannot trust the program you run on the server, you add an additional laye

• zzzcpan 10y ago
  Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities, just take place directly in the code, not on the OS level. Things are a bit more complicated with image libraries though, because a) performance is usually critical and b) even if you have that casual use case and it's not yet critical, memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!), unless you apply those mitigation techniques and deploy supporting infrastructure to prevent process from using all memory and all CPU and take too long, etc.
  • stymaar 10y ago
    > Bounds checking and panicing are similar mitigation techniques and not an actual freedom from memory-born vulnerabilities Absolutely. Bounds checking is a mitigation technique to avoid potential footgun when you want/have to use manual array indexing. In most situations in Rust, you use iterators instead of array indexing. Those are the «actual freedom from memory-born vulnerabilities» and have no associated overhead. Since it is known at compile time that you are not going to access invalid memory, there is no need for bounds checking in this scenario. Most of rust safety comes from clever compile time checks with no additional cost at runtime. The two main counter-examples I can think of are : - bounds checking on manual array indexing - usage of a secure hash function by default in HashMaps The whole story about safe multi-threading and dangling pointers prevention is totally free performance-wise: everything is checked at compile time by the borrow checker. > memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks (not even talking about malicious users here!) You're right, Rust doesn't solve all the problems at once. Is it a good reason to get rid of the benefits of solving the worst 50% of problems ?
    • zzzcpan 10y ago
      > Is it a good reason to get rid of the benefits of solving the worst 50% of problems ? Again, not for images. I believe the real reason is different, Rust people simply want to have an image library in its ecosystem, just like Go. Nothing wrong with that goal, makes it more appealing to new users. But that's it.
  • oconnor663 10y ago
    > not an actual freedom from memory-born vulnerabilities "Memory-born vulnerabilities" sounds like a broad term, and if it includes DOS issues then Rust code is as vulnerable as anything else. But it's worth being precise: Rust's security model is about preventing undefined behavior. If you have an out-of-bounds array write in C, that could do anything to the program. But in safe Rust code, all it can do is panic. Like you said, that's not necessarily any different from a DOS point of view, but it rules out a huge class of remote-code-execution bugs and leaks like Heartbleed. Of course it's still possible to write bugs and leak something you didn't mean to leak, but it shouldn't be possible to do that in a totally unrelated part of your process, and that's a big deal.
  • pcwalton 10y ago
    > memory safety is still not going to make it free from vulnerabilities to accidental DoS attacks What kinds of DoS attacks are you thinking about that aren't covered by simply limiting the size of the images you need to parse? I mean, I've written a PNG decoder and the only dynamic allocation I can think of that I needed was the actual decoded image data.
    • tinus_hn 10y ago
      PNG compresses the image data using the DEFLATE algorithm. You can write data that decompresses to almost 1023 times the size of the compressed data. So if you allow 1 MB images, be prepared to allocate memory for and process about 1 GB of data.
      • Rusky 10y ago
        PNG also explicitly specifies image dimensions, so there's no need for that at all.