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

221–230 of 280 posts

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

#221

Post by Cloudef »

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…

It's funny because C compilers have warnings for these, but you have to explicitly enable them. Typically my stuff looks like: -Wall -Wextra -Wpedantic -Wformat=2 -Wstrict-aliasing=3 -Wstrict-overflow=3 -Wstack-usage=12500 -Wfloat-equal -Wcast-align -Wpointer-arith -Wchar-subscripts -Warray-bounds=2

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

#222

Post by dirkt »

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?

A better alternative would be to keep PID1 as simple as possible, and do anything more complex in a subprocess.

Systemd of course goes in the opposite direction: It assimilates as much functionality as possible from the OS into systemd (though to be fair, not all into PID1).

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

#223

Post by Cloudef »

xeeeeeeeeeeenu wrote: post #98
morio wrote: post #33

Earlier quoted context omitted.

What kind of false positives are you seeing with gcc? Personally I have never seen gcc spitting out a false positive. IMO it's always a good idea to explicitly downcast even if you know that it's 'safe'. That way someone else will see instantly what's going on. The fact that Rust requires it should tell us something.

For example, I've just reported this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537 You can find more cases in the bugtracker. To be fair, it seems many of them were fixed in recent releases.

The 1 and 0 are ints. It most likely complaints because the sign isn't same.

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

#224

Post by ehvatum »

alerighi wrote: post #192
merb wrote: post #173

Earlier quoted context omitted.

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.

It's not a mistake. Allocating that string on the stack it is not a bad idea. Most of the time the string will be short, and thus an allocation on the stack is faster. Consider that in Linux a path is defined to be a maximum length of PATH_MAX, that is defined to 4096 bytes, and a filename (and directory name) shouldn't be longer than FILE_MAX that is 255 bytes. This limits are defined in the headers and I use them a…

> The filesystem doesn't support it.

Remember that Linux supports hierarchical mounts! You can mount anything at any depth of directory nesting. Even if it were true that MAX_PATH were an FS limitation, you could still nest mounts and encounter absolute paths exceeding MAX_PATH. MAX_PATH is simply the length in bytes of the longest string you should expect system calls to accept as a path parameter.

> I use Linux computer with 16Mb of RAM, total. Of course they don't run systemd nowadays since it's too big, but in my opinion systemd is good, and I would like to see it more in the embedded world.

It sounds like using systemd is a terrible idea for memory-constrained devices, so you really don’t want to see it in the embedded world.

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

#225

Post by a1369209993 »

afc wrote: post #208
michaelmrose wrote: post #195

Earlier quoted context omitted.

Or just don't put stuff that crashes in pid1

Yeah, great idea: rather than worry about how to deal with software bugs, just never have bugs...

Exactly. This is why systemd is a terrible design. The fastest and most secure code, that never crashes and never needs patching, is code that doesn't exist.

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

#226

Post by bigiain »

fomine3 wrote: post #220
bigiain wrote: post #204

Earlier quoted context omitted.

"Lets put the graphics drivers in ring 0, for better performance!" -- Windows NT architects, 1996 "Ummm, lets not do that, it's not such a great idea..." -- Windows Vista team, 2006

Initial Windows NT uses user mode graphic driver, then NT 4.0 move it kernel mode. https://docs.microsoft.com/en-us/previous-versions//cc750820...

Yep. In about '96.

(Well, it came out late '96, so I suppose a bunch of that was actually done in '95.)

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

#227

Post by josefx »

alerighi wrote: post #194
megous wrote: post #161

Earlier quoted context omitted.

Yep: https://github.com/systemd/systemd/commit/b34a4f0e6729de292c... strdupa(input) without any length check Fix is to replace it with unbounded malloc() instead of checking for sane length first.

This fix to me reduces the performance for nothing. In Linux (or most general on any UNIX system that I saw) a path should not be longer (total) than PATH_MAX, that is typically defined to 4096 bytes. What is the point on allocating something statically at this point? And yes, I know that really that is only a limit of the system call path lenght, and in theory you can work with longer paths (by changing the current…

> In Linux (or most general on any UNIX system that I saw) a path should not be longer (total) than PATH_MAX, that is typically defined to 4096 bytes.

That almost sounds like the 260 character windows path limit constant used by some ancient APIs. I would assume that any API limited to that path length is dated and probably unreliable in various contexts as the wikipedia article on filesystems explicitly gives the limit as not defined for various Linux filesystems. Also given the recent talk about in kernel support for NTFS (path limit ~2^16) I assume that any historic code still relying on PATH_MAX needs to be fixed.

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

#228

Post by pjmlp »

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…

Maybe,

"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. "

https://www.bell-labs.com/usr/dmr/www/chist.html

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

#229

Post by a1369209993 »

est31 wrote: post #138
eloff wrote: post #85

Earlier quoted context omitted.

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.

When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either. That being said, by the time 128 bit run out we have probably boiled earths oceans :). You could think of checked memory models where half of the 256 bit address is a 128 bit random key needed to access some allocation, or maybe even a decryption key. Similar things are done with the extra space of x64 a…

> When 16 bit computers went to 32 bit, people probably thought that one wouldn't ever need 64 bit computers either.

People have said that about pretty much every memory size in the history of computing. The argument for 64-bit is not "2^64 bytes ought to be enough for anyone"; it's "you couldn't use more than 2^64 bytes even if you wanted to". Writing a full register worth of data every clock cycle at 4GHz works out to 32GB/s. (2^64B / 32GB/s) is just over seventeen years, to fill up a 64-bit address space, assuming you're doing no actual computation. Few computers even work for seventeen years without replacement, much less run single processes continually with no reboots.

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

#230

Post by ridiculous_fish »

saagarjha wrote: post #164
ridiculous_fish wrote: post #80

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.

Apple benefits from compatibility with the ARM ecosystem, but there’s no downsides (from their perspective) from extending it. Their chips are “Apple Silicon”, setting the stage for forging ahead alone. I think it’s a card they hold in reserve, to be played when the time is right, like the Intel transition.
Post reply on HN