181–190 of 280 posts
Afaik this should work on Android for some time now too right? Got unrootable old (but still fully working) phone there, might try to play with it.
B doesn't have these issues because it only has one integer size, take that C.
Earlier quoted context omitted.
Probably unbounded alloca() as always.
was that a guess? wtf... btw. it would probably be hard to make the same mistake in rust. unless you write your own code for strings or use strdupa, too via libc. I also do never understand why some libraries use "faster" methods everywhere, unless safer ones. it's not like all interfaces to systemd would need to be fast. but they should be secure.
https://capsule8.com/blog/exploiting-systemd-journald-part-1...
Earlier quoted context omitted.
-Wall -Wextra -Wpedantic does not enable all diagnostics. This is GNU's idea of "all". Contrast to Clang's -Weverything, which will.
> This is GNU's idea of "all". Unfortunately, over the years people baked the semantics of -Wall into their builds so new diagnostics could not be added to that flag. And clang’s -Weverything shows how the opposite can fail as well
Also there are some warnings that won't be produced if you compile without optimization, because the needed analysis isn't performed.
Earlier quoted context omitted.
It's generally dangerous to restart PID1 in an enviroment where, by definition, something happened to PID1 that it wasn't expecting. The state of the system is now unreliable, and it's exactly the sort of unreliable in exactly the right place that tends to lead to whopping security issues. Far too easy to end up with "Crash PID1 with 'blah blah blah', then when it restarts it ends up doing bad things X & Y".
Perhaps a distinction here can be made between running as a server OS and a desktop OS. In a server I generally want a crash immediately. But on a desktop I'd rather it limp along and give me a chance to finish writing my Hackernews post.
It depends really what your server does, and what the consequences of it doing the wrong thing are.
Earlier quoted context omitted.
> you simply have failed as a programming language designer That's some hubris. The C language is 49 years old. Dennis Ritchie made reasonable design decisions for the time he found himself in. I think we should be understanding of that, and the network effects that lead to large parts of the world's critical software infrastructure being implemented in C. I don't think he failed at anything. I used to be a C develop…
>The C language is 49 years old. That’s my point, no shade on K&R though.
age is orthogonal to good design.
Earlier quoted context omitted.
into() does not work from size. It's rather frustrating in practice. https://stackoverflow.com/questions/62832438/why-is-rusts-us...
Yeah, that is frustrating since there are no platforms where that would fail today, and it's hard to imagine why we would ever want one with 256bit pointers. We don't even use full 64bit pointers today on x64.
I love the little nugget in the mitigations section. You can plug the hole for a normal filesystem, but then FUSE filesystems have an additional problem: "if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack, crashes, and therefore crashes the entire operating system (a kernel panic)." If there's one place other than the kernel where truly defensive programming should be appl…
Wait how does a user space daemon exhausting its stack lead to a kernel panic?
> Unfortunately, this size_t is also passed to functions whose size argument is an int (a signed 32-bit integer), not a size_t. Is this the type of things that could be caught by a linter or strict compilation rules? This seems to be to be a failure of the type system.
Yes, it is the type of thing caught by a linter or strict compilation rules. https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel... But strict compilation rules (eg, clang's -Weverything) mainly only work if you treat them as errors (so -Werror), and then some of those strict are then also questionable at best, and just outright annoyingly wrong at worst. For example, unused parameter warnings on virtual met…
Why is that even a warning? If at least one of the implementers use a parameter and a warning is shown the warning itself is wrong. That’s just broken implementation of the warning?
Earlier quoted context omitted.
The compiler can issue warnings for this. This os why in C it is a good practice to enable all compiler warnings and to have the compiler treat warnings as errors.
In theory but not in practice if you're distributing your apps sources. If you write for C compiler Foo 8, there's a decent chance Foo 9 will raise a warning which didn't exist before. Now you have to handle "why doesn't this compile" issues and distributions have to patch your sources to do future releases. And that's ignoring bugs like GCC in the past where in some versions you could not satisfy specific warnings.
But never ever leave -Werror enabled for building in Release mode. You'll be preventing your code from building as soon as a new compiler version goes out. Maintainers or code archeologist will have a much worse time than if this option was simply disabled to start with.