6 ms·

Just curious whether Rust would have averted these issues?

• voxl 3y ago
  The answer is probably yes. The issue is caused by a heap-memory overflow. In Rust, if you're storing an array on the heap then there will be bounds checks on the array access. If you're using a vec then it would automatically grow (so again bounds checks).
  • ape4 3y ago
    It would be quite something to rewrite glibc in Rust! Of course, its the C/C++ run time.
    • yjftsjthsd-h 3y ago
      It's a funny thought, but I don't think there's any reason it shouldn't work; IIRC redoxos is providing a libc written in rust for compatibility.
      • Retr0id 3y ago
        The redox impl is here: https://github.com/redox-os/relibc https://github.com/redox-os/relibc Apparently it also supports linux!
    • Retr0id 3y ago
      It would be quite amusing, but there's no reason in principle that it couldn't be done. The user-facing APIs would be just as dangerous as ever, but the internal implementation-detail stuff - like this "__vsyslog_internal" - could presumably be made safer.
    • pjmlp 3y ago
      As C++ advocate on C vs C++ flamewars, I already find quite ironic that GCC, clang, clang's libc and Windows Universal C Runtime are all written in C++. All those C users hatting on C++, while being forced to use tooling that has dropped C for C++.
      • tmtvl 3y ago
        > All those C users hatting on C++ Such haberdashery! Anyway, something that I appreciate about the Rust community is their dedication to rewriting anything and everything in Rust. I'd love it if the Lisp community also had some of that drive. Seeing a library which uses a Python script to generate documentation is so disheartening, they don't need that horrendous, awful garbage, they could just do it in Lisp.
        • gnabgib 3y ago
          I can't quite guess what you meant (balderdash[1]?), but I'm pretty sure you didn't mean a goods and wears shop[0] [0]: https://www.merriam-webster.com/dictionary/haberdashery https://www.merriam-webster.com/dictionary/haberdashery [1]: https://www.merriam-webster.com/dictionary/balderdash https://www.merriam-webster.com/dictionary/balderdash
          • tmtvl 3y ago
            Because 'hating' was misspelled 'hatting' I did mean to refer to a provider of men's wear such as hats.
      • uecker 3y ago
        Indeed it is a shame. All bloated. It would be nice to have small and lean tool chain again.
      • flohofwoe 3y ago
        You're not exactly "forced" to use the C stdlib though. That's one nice thing about C, that the C stdlib is so bare bones that it could just as well not exist and not much would be lost (much harder to ignore the stdlib in C++, at least for some "modern C++" features). Besides: MUSL is written in plain C ;P
        • pjmlp 3y ago
          Yeah, but that isn't C any longer, it is a flavour of a language that largely looks like C. C is the complete printout from ISO/IEC 9899.
    • nindalf 3y ago
      Yeah it would. There are a few attempts, such as C-gull (https://github.com/sunfishcode/c-ward/tree/main/c-gull#readme https://github.com/sunfishcode/c-ward/tree/main/c-gull#readm...). > c-gull is a libc implementation. It is an implementation of the ABI described by the libc crate. > Currently it only supports --linux-gnu ABIs, though other ABIs could be added in the future. And currently this mostly focused on features needed by Rust programs, so it doesn't have all the C-idiomatic things like qsort yet, but they could be added in the future.
    • flohofwoe 3y ago
      It's not so unusual to write the C stdlib in a different language. E.g. Zig is getting a libc written in Zig: https://github.com/ziglang/zig/issues/514 https://github.com/ziglang/zig/issues/514 Rust would work too of course. MUSL is probably the only popular C stdlib actually written in C.
      • 2OEH8eoCRo0 3y ago
        I think their point is that the c in glibc stands for C, as in the language. A glibc rewrite in Rust wouldn't be glibc anymore!
        • wongarsu 3y ago
          Well, the Common Language Runtime that powers .Net languages isn't written with .Net, and the Java runtime environment isn't written in Java. I know these are a lot more involved than the functions provided by the glibc, but the point is that libc means Library for C, not Library in C. And of course on Unixes all software is expected to link to the glibc for basic functionality, no matter whether it's written in C or not. So the name is only historically accurate.
          • wrs 3y ago
            Yes, but even more so. Linux “expects” programs to link to libc, but many other Unix-like OSes require programs - in any language — to link to libc. The kernel syscall interface is not considered a stable API. Windows has a similar structure, but the required kernel interface library is not the same one as the C runtime, so it’s less confusing language-wise.
          • pjmlp 3y ago
            > Well, the Common Language Runtime that powers .Net languages isn't written with .Net, and the Java runtime environment isn't written in Java. Actually a large part of it is, and in Java's case there are bootstraped implementations, OpenJDK isn't the only one. Java is like C and C++, where multiple implementations are available for a given specification. https://docs.oracle.com/javase/specs/ https://docs.oracle.com/javase/specs/
  • loeg 3y ago
    Yeah, unless you bypassed the bounds checking with unsafe{} for performance reasons. (The is an unlikely place to do so.)
  • uecker 3y ago
    There was a similar bug in the past in Rust: Integer overflow causing a buffer overflow: https://github.com/rust-lang/rust/pull/54399/commits/8ac88d375e00c91a3db5d78852048322f88be3c1 https://github.com/rust-lang/rust/pull/54399/commits/8ac88d3... So the answer is: Not necessarily. I agree though that the memory safety features in Rust would help reduce the risk. On the other hand, one could also write safer C by abstracting away buffer management. The world is not black and white.
    • e44858 3y ago
      That function was using an unsafe block to disable the bounds check. This kind of bug would likely be impossible in "safe" rust (that didn't use unsafe).
      • ajross 3y ago
        The linked glibc code was likewise being fancy trying to use a stack buffer to avoid a heap allocation. Idiomatic C would have worked just fine too. The point is that Rust is also (though not as severely) subject to developers playing tricks and hurting themselves.
      • uecker 3y ago
        In reality people use unsafe to optimize and then introduce bugs. You could also use a safe abstractions to avoid bounds violations in C.
        • zamalek 3y ago
          That isn't the use-case for unsafe. If you see a codebase doing this then you should stop paying attention to or using that codebase. Unsafe is for creating things that are beyond the understanding of the borrow checker. For example, using unsafe is mandatory for creating a mutex because the safety rules are upheld by the data structure itself. Unsafe is not "C mode" as most would assume - it is more unsafe than C because if you don't uphold the memory model things will break. Rust's strict aliasing and mutability rules provide ample opportunity for compiler optimizations and zero cost abstractions. Turning to unsafe is generally a sign of incompetence/arrogance.
  • ajross 3y ago
    It's actually questionable. The vulnerable code is described really well in the Qualys report: https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt Basically: the code was an optimization trying to avoid a heap allocation by using a stack buffer instead, but its fallback for "it doesn't fit in 1k of stack memory" wasn't tested and didn't work right. Rust struggles with alloca-style code too, to the extent that users who want to do this kind of trickery usually resort to unsafe. There's a link elsewhere in this topic to a Rust library vulnerability that looks similar. The upshot is that if the code had been written idiomatically and just used the heap like it was supposed to, it probably would have worked fine. The glibc authors got fancy, loaded a footgun, and it went off, something that Rust is equally capable of.
    • deathanatos 3y ago
      > Rust struggles with alloca-style code too, to the extent that users who want to do this kind of trickery usually resort to unsafe. Sort of, but not really. I've done this sort of "if it fits in a small stack buffer, use that, else fall back to heap" in code too. It's possible in safe-ish Rust: let mut s = SmallString::<[u8; 1024]>::new(); write!(s, "{} frobs for {} widgets.", var_a, var_b) .expect("writes to a String are infallible"); Safe-ish, because there is an unsafe {} hidden behind the safe interface exposed by `SmallString`. (And that crate has had vulnerabilities against it.) But that's sort of the point: we're here looking at logging code, and the logging code itself shouldn't be doing this sort of unsafe trickery, it should be using some interface/utility that handles that, and then there's only a single spot that needs safety analysis. (Here, that would be the smallvec crate.) While I don't think C outright prevents you from building an equivalent, certainly how people tend to approach C does, and we see that here. The pattern is unsafe at the instantiation site, not at the definition, leading to far more unsafe code. (Not to mention the fact that in C, we have no unsafe {} blocks, so one must assume all such code is unsafe, but even if we just consider the laughable and impossible-to-grep "just the actually unsafe parts", it's far, far more.) In the C at hand here, the second attempt here fails due to a variable never truly getting initialized (in the sense of having a meaningful value), and the version prior to that is just laughably unsafe, allocating a 1 byte buffer but passing a size far larger. (The second attempt (i.e., time of bug) also uses the cursed variable name `l`, and the site this code is hosted on uses a font where `l` and `1` are homoglyphs.)
  • WhereIsTheTruth 3y ago
    rust disables bound checking in the release builds, so no, you are wrong
    • steveklabnik 3y ago
      Rust does not disable bounds checks in release builds.
      • WhereIsTheTruth 3y ago
        It does, as well as overflow checks, you can re-enable everything to be safer with a custom build profile, but you'll loose at benchmarks
        • steveklabnik 3y ago
          Overflow checks turn into two's compliments' wrapping, but that's only considered acceptable because bounds checks are not turned off. https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f077ed9ee71c0d1a212ec49c24a576cf https://play.rust-lang.org/?version=stable&mode=release&edit... EDIT: I wonder if you're thinking about how sometimes bounds checks are optimized away? It is true that that will happen in release mode more than debug mode, but those are only the checks that can be proven redundant, if there is any doubt, they will not be optimized out. Semantically, they are still there.
• foobiekr 3y ago
  There's a kind of naive thing going on on HN where peopel see a bug and ask whether or assert Rust will fix it. The problem is they are homing in on just the bugs Rust addresses - this is fine, I've had this conversation at work (not involving Rust, even) for two decades, including discussions about Java. The problem is that Rust solves _a_ class of issues without even beginning to address other kinds of problems, and so this sort of thinking is evolving toward a mindset that "oh it's rust so no security issues", which is completely wrong.
  • eichin 3y ago
    Perhaps an innoculation against this is to respond "Yes, but so would Ada"
    • pjmlp 3y ago
      I keep using "mostly safe languages" as kind of abstract term, Rust comes into speech even in scenarios where other alternatives would be a viable option.
    • foobiekr 3y ago
      Ada is such a lost opportunity honestly. As powerful as C, performant and clean.
      • pjmlp 3y ago
        Unfortunely did not come with an OS, wasn't freely available, and quite costly. Remeber that until AT&T was allowed to take commercial advantage of UNIX, its source code was available for a symbolic price, and it came with a C compiler toolchain, at least until Sun started the trend among UNIX vendors of spliting UNIX development tools into an additional purchase. The UNIX vendors that had Ada compilers, that was an additional purchase on top of UNIX SDK (which already had C and C++), so unless there was a hard requirement to use Ada, no one bothered to pay extra.
        • foobiekr 3y ago