Live data from Hacker News

size_t-to-int vulnerability in Linux’s filesystem layer

openwall.com

171–180 of 280 posts

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#171
post #72
post #63

Earlier quoted context omitted.

> and the compiler doesn't even warn you that size is bigger than x That's not true tho, compiler with reasonable flags set will definitely warn you and if you really don't like this kind of code you can force compiler to issue an error instead

What flags you have in mind? Because this code doesn't generate any warning with GCC 11.1.0 with -Wall -Wextra: int main(void) { int some_int = 1234567; char c = some_int; return c; }

-Wconversion will catch this

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#172
post #7

This kind of issue is the reason why some more modern languages like Rust or Go do not have implicit narrowing conversions. For instance, on Rust, trying to simply pass an usize (Rust's equivalent of size_t) to a function which expects an i32 (Rust's equivalent of int) will not compile; the programmer has to write "size as i32" (Rust's equivalent of "(int) size"), which makes it explicit that it might truncate the va…

I think Rust has no language construction for that, but the best implementation of "size as i32" should fail on overflow.

In Haskell I would use an exception, and mark the function as unsafe, but the stdlib seems to disagree with me here.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#173
post #159
post #154

Earlier quoted context omitted.

What the hell is systemd doing that a 8MB long file path can exhaust its stack? Is it doing some recursive parsing or is it just doing something plain stupid like using a VLA to store user provided data?

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.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#174
post #130
post #101

Earlier quoted context omitted.

The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. I can see the reason behind it, but I feel that this behavior is something you opt into when you use -Werror.

> The reason for this decision is so that compiler upgrades with -Wall and -Werror don't break builds. It feels like the "right thing" here would instead be for the compiler to allow build scripts to reference a specific point-in-time semantics for -Wall. For example, `-Wall=9.3.0` could be used to mean "all the error checks that GCC v9.3.0 knew how to run". Or better yet (for portability), a date, e.g. `-Wall=202107…

The real solution: leave Werror off by default, activate it only during CI builds

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#175

Earlier quoted context omitted.

CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that code get messed up? Would it be possible to just silently replace with arbitrary sized integer and not break any code like safeintadd?

CPUs don't raise exceptions, that is a software concept. CPUs do have traps, like for division by zero, but those are not exceptions in the way you think. Null pointers are also handled by the kernel, not the CPU. Its called a segmentation fault because you are trying to access a memory segment that the OS doesn't want you to.

I dont think kernel handles NPEs: https://stackoverflow.com/questions/63091446/what-happens-at...

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#176
post #149

Earlier quoted context omitted.

CPU would raise a signal just as null pointer exception? And it seems a lot of code (for eg, safeintadd metioned below) assumes no exception. Would not all that code get messed up? Would it be possible to just silently replace with arbitrary sized integer and not break any code like safeintadd?

In C, you can't "just" replace with arbitrary-sized integers. They are fundamentally different memory shapes. You may not be able to turn enforcement on for all code immediately. There's even the rare bits of code that depend on current overflow behavior. (Due to our human brains and the fact that we can easily name these bits of code, making the cognitively available, people often grotesquely overestimate the amount…

I feel like carefully planned with compiler level errors(not warnings), and some glibc non-backward compatible changes. we can achieve this in software layer.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#177
post #153

Earlier quoted context omitted.

I wonder if just restarting PID1 could be viable alternative?

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.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#178

Earlier quoted context omitted.

Swift checks all arithmetic by default: https://swift.godbolt.org/z/rW614G5aq It seems obvious that future Apple CPUs will have hardware support for this, if they don't already.

I don’t see this happening unless it makes it into the ARM ISA.

I'm not familiar with ARM ISA, but from the godbolt disassembly, it doesn't look like anything special going on here - just the ASM being generated. What's happening here is it just does the add, jumps on overflow flag set to an invalid opcode...

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#179
post #169

Earlier quoted context omitted.

I don’t see this happening unless it makes it into the ARM ISA.

I don’t know the terms of Apple’s license with ARM, do you? I’m quite interested. Given that Apple was one of the original founders of ARM it’s quite possible that their license allows much more latitude anyone else’s.

Adding new instructions to userspace programs is almost certainly not going to fly. All of their extensions have been hidden behind an opaque API, or limited to use in the kernel.

Re: size_t-to-int vulnerability in Linux’s filesystem layer

#180

Earlier quoted context omitted.

I don’t see this happening unless it makes it into the ARM ISA.

I'm not familiar with ARM ISA, but from the godbolt disassembly, it doesn't look like anything special going on here - just the ASM being generated. What's happening here is it just does the add, jumps on overflow flag set to an invalid opcode...

The suggestion was a custom instruction or architectural extension to have this happen in hardware, rather than needing to write out extra code for this.
Post reply on HN