Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

151–160 of 280 posts

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

#151

Post by scns »

tialaramex wrote: post #91
eloff wrote: post #78

Earlier quoted context omitted.

I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild when you want to move to the newer edition.

I don't see it as a big job. Am I wrong? Imagine there's a suitable narrow:: () function introduced which has the same consequence, always narrowing, if your data was too wide it may drop important stuff on the floor, and narrow() just says that's too bad. Rust 2030 can introduce narrow:: (), warn for narrowing as usage and then Rust 2035 can error for as. The Rust 2030 -> 2035 conversion software can consume code th…

Yes, BUT the correct thing to do would be more tedious to write that way.

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

#152

Post by Denvercoder9 »

comex wrote: post #69
unmole wrote: post #60

Earlier quoted context omitted.

Wait how does a user space daemon exhausting its stack lead to a kernel panic?

Because the kernel intentionally panics [1] if the init process would otherwise exit in any way – whether because it called exit(), it was killed, or, in this case, it crashed. This is likely because Unix semantics treat the init process specially: any process whose parent dies is re-parented to the init process. It's not clear what should happen to these processes if the init process itself went away, so the kernel…

I wonder if just restarting PID1 could be viable alternative?

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

#153

Post by jerf »

Denvercoder9 wrote: post #152
comex wrote: post #69

Earlier quoted context omitted.

Because the kernel intentionally panics [1] if the init process would otherwise exit in any way – whether because it called exit(), it was killed, or, in this case, it crashed. This is likely because Unix semantics treat the init process specially: any process whose parent dies is re-parented to the init process. It's not clear what should happen to these processes if the init process itself went away, so the kernel…

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".

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

#154

Post by josefx »

mnw21cam wrote: post #8

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…

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?

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

#155

Post by Denvercoder9 »

usefulcat wrote: post #146
gruez wrote: post #3

Earlier quoted context omitted.

AFAIK most compilers by default will output a warning in this case.

GCC's -Wconversion has some issues. For example, good luck getting gcc to /not/ emit a warning for this code, in C or C++. I have yet to find the appropriate cast to avoid a warning. Clang does not warn for this. typedef struct { unsigned value : 4; } S; void foo(S* s, unsigned value) { // error: conversion from 'unsigned int' to 'unsigned char:4' may change value s->value = value; } I mean, I guess I can see the rat…

Does it still warn if you do `s->value = value & 0x0F`? That seems like a reasonable alternative to pragmas if it works.

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

#156

Post by lazide »

aaronmdjones wrote: post #82
simias wrote: post #72

Earlier quoted context omitted.

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; }

-Wall -Wextra -Wpedantic does not enable all diagnostics. This is GNU's idea of "all". Contrast to Clang's -Weverything, which will.

It seems though that the point is made, right? Even 'good' approaches miss on what should be a clear 'whoa, are you sure?' type warning. There are a lot of footguns wandering around in C/C++ land.

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

#157

Post by MauranKilom »

verytrivial wrote: post #140

I honestly think all the automatic type promotion and conversion rules of the C family should be officially classified as "cute", namely an example of a childish simplification of a serious issue. I'm a C++ programmer of 20+ years experience and I have never, NEVER, caught myself thinking "gee, I'm glad I don't need to cast this." You ALWAYS think it, you just don't TYPE it, and that is the utterly wrong metric to op…

I've had my fair share of annoyance from situations like "I have between one and four hard-coded insertions into this vector, but the compiler yells at me if I try to store the resulting size in an int".

Also, tangentially related is the signed/unsigned business which tends to get in the way frequently. For example, OpenMP 2.0 (the only OpenMP version you get to use with MSVC) requires loop indices to be signed, but both std::vector::size and std::vector::operator[] deal with unsigned integers. Casts guaranteed!

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

#158

Post by fulafel »

eloff wrote: post #85
ridiculous_fish wrote: post #36

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.

Maybe a fat pointer llvm target ala SoftBound running on a machine with 128 bit bare pointers, like as/400.

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

#159

Post by megous »

josefx wrote: post #154
mnw21cam wrote: post #8

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…

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.

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

#160

Post by cannabis_sam »

andyjohnson0 wrote: post #120
cannabis_sam wrote: post #113

I’m still amazed that we allow compilation of so obviously faulty programs. It’s like you sent a 1kg package through the postal service, and then the recipient gets an envelope containing a piece of cardboard from the original packaging.. And everyone involved is somehow A-OK with all of this. If your programming language silently converts between types (in any direction), just to accommodate the programmer, instead…

> 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.

Post reply on HN