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

201–210 of 280 posts

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

#201

Post by agalunar »

dahfizz wrote: post #135
airocker wrote: post #131

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.

It's worth noting that the term "exception" is in fact used for traps that aren't interrupts.

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

#202

Post by sinsterizme »

rtldg wrote: post #197
sinsterizme wrote: post #191

Earlier quoted context omitted.

Shouldn't this PR also use `free` on the duped string before returning? (I never use C so probably missing something but just based on the docs of strdupa...)

The variable p is now declared with "_cleanup_free_" which is using some compiler cleanup/destructor attribute stuff to run free

ah okay, thank you :)

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

#203

Post by bigiain »

londons_explore wrote: post #185
cameronh90 wrote: post #177

Earlier quoted context omitted.

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.

On a server I'd usually want it to limp along too... Better fire an alert but keep happy customers than cause a massive outage just because of someone's overly strict checkfail... It depends really what your server does, and what the consequences of it doing the wrong thing are.

If the consequences of one server wedging itself is a "massive outage" and "unhappy customers", then you probably don't really care about that outage or those customers. If you don't have enough redundancy and alerting and automated disaster recovery to keep your customer facing shit up when one server panics, you're just relying on luck to keep your customers happy.

Fire an alert, remove that server from the load balancer, and fix the problem without your customers even noticing.

Or make sure if you're running a hobby-project architected platform that your customer expectations and SLAs are clear up front, and let it go down until Monday morning when you'll get around to fixing it.

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

#204

Post by bigiain »

mjevans wrote: post #188
unmole wrote: post #60

Earlier quoted context omitted.

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

Poorly designed security architecture and division of labor. A more idealized init / systemd would have all of the execution flow of PID 1 mathematically provably correct, and correspondingly have as small a footprint as possible there. All additional functions would run under one or more child processes (where the bulk of systemd would execute).

"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

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

#205

Post by ohazi »

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…

> reduces the performance for nothing

Does the code in question ever run in a tight loop (e.g. on file operations after the filesystem is mounted), or just at mount time?

If it's just at mount time, "reducing performance" by one malloc vs a stack adjustment doesn't seem to me like it should be a primary concern.

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

#206

Post by anyfoo »

anyfoo wrote: post #116
greesil wrote: post #35

https://org.cs.pub.ro/dragos.tarcatu/llvmlinux/commit/058504... m->size must be of type size_t. It's slightly mind-blowing to me that casting to a smaller unsigned int can cause a vulnerability. But I guess unintended behavior (not undefined) can do that.

It's very common. All that needs to happen, as just one example, is the variable of the smaller type being used as an index into an array. You might get an out of bounds access, or even just an access to the wrong element.

To add to my own comment, more realistically this happens if the variable is used in the calculation of an index, rather as directly as the index. Though if the array is sufficiently large, and/or the smaller type sufficiently small (short or even char, which are most often 16 or 8 bit nowadays), then at least accessing the wrong element is still common (out of bounds less so). Well, you get the overall idea.

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

#207

Post by TheCycoONE »

pornel wrote: post #187
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.

Even worse, there are platforms with >=128-bit pointers but 64-bit address space. Rust has chosen usize to be uintptr_t rather than size_t, even though it mostly uses it as if it was size_t. A ton of code is going to subtly break when these two sizes ever differ. Rust is likely already doomed on >64-bit platforms, and is going to be forced to invent its own version of a LLP64 workaround.

Sorry, I'm not sure how this is a problem. On segmented architectures size_t is smaller than uintptr_t, but that just means there needs to be an allocation limit It would have cause more bugs if they defined it the other way and people used usize to store addresses.

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

#208

Post by afc »

michaelmrose wrote: post #195
londons_explore wrote: post #185

Earlier quoted context omitted.

On a server I'd usually want it to limp along too... Better fire an alert but keep happy customers than cause a massive outage just because of someone's overly strict checkfail... It depends really what your server does, and what the consequences of it doing the wrong thing are.

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

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

#209

Post by michaelmrose »

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

runit.c is 330 lines of code

Keeping it small and simple to minimize bugs is perfectly viable and reasonable.

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

#210

Post by [deleted] »

megous wrote: post #161
megous wrote: post #159

Earlier quoted context omitted.

Probably unbounded alloca() as always.

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.

[deleted]
Post reply on HN