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

231–240 of 280 posts

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

#231

Post by zaarn »

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…

Fun fact: PATH_MAX and FILE_MAX are glibc/muslc limitations. The Linux Kernel doesn't have a limit here and will happily let you walk into a directory with a 2GB pathname.

ext4 doesn't limit directory depth; only filename length. A filename can be 255 bytes in ext4. How deep that lies in the filesystem isn't limited.

btrfs has the same filename limit, no underlying limit on directory depth.

And I would most likely guess most filesystems don't because the obvious ways to implement directories don't place limits on that depth.

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

#232

Post by masklinn »

saagarjha wrote: post #179
gumby wrote: post #169

Earlier quoted context omitted.

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.

That… makes no architectural difference at all. As far as the architecture is concerned, these are architectural extensions either way: userspace programs can observably contain and execute instructions which are not standard ARM.

If AMX is allowed under their license, there is no reason why checked extensions would not be.

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

#233

Post by masklinn »

tialaramex wrote: post #95
phkahler wrote: post #83

Earlier quoted context omitted.

This wouldn't be a problem if "int" was defined as the same size as size_t. The solution is probably to change all those functions to take a parameter of size_t instead of int. IMHO one should always be using C99 types instead of int, but Linux predates that. Also, shouldn't that implicit conversion cause a compiler warning?

Linux apparently provides a similarly named set of sized integer types to Rust, ie: s8 u8 s16 u16 s32 u32 s64 u64 But of course getting C programmers to use these integer types rather than the ones they grew up with isn't easy.

I don't think that stops C's implicit conversions either, does it?

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

#234

Post by masklinn »

formerly_proven wrote: post #112
habibur wrote: post #107

> deep directory structure whose total path length exceeds 1GB [...] Oh, I didn't know Linux supports GB long path name. On Windows it's limited to something like MAX_PATH_LENGTH which was defined as 200+ chars when I worked on it.

Windows goes to 260 chars, but the underlying system supports something like 64K, which means you can have files on Windows which are largely untouchable by built-in tools (Windows Explorer, file dialogs etc.)

Windows goes way beyond 260, but for BC purposes historically you needed UNC paths (and UNC-aware APIs?).

Since W10 Anniversary Update, there is a setting to disable the MAX_PATH limitation in various APIs, but applications still have to opt into long path awareness via a manifest key.

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

#235

Post by masklinn »

divingdragon wrote: post #115
Already__Taken wrote: post #110

Earlier quoted context omitted.

Windows lifted that limit a few years ago

IIRC you still need to use a special flag to enable it, right?

There are two things necessary for an application to use long paths:

* the system must have LongPathsEnabled set (though it might be the default nowadays, not sure)

* the application itself must have `{http://schemas.microsoft.com/SMI/2016/WindowsSettings}longPa...` set in its manifest

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

#236

Post by opheliate »

BoorishBears wrote: post #162
lazide wrote: post #156

Earlier quoted context omitted.

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.

No, the point was you want don't get a warning and it will silently wrap. You can scroll up if you've forgotten. And it is false. My default configuration C++ project created in Clion shows it very clearly, and even pesters to use int32/int64 over int/long. But as usual the default fallback when you're wrong about C++ is "uh yeah but lotta footguns amirite" As if there aren't enough that we need to start making them…

And yet RedHat's recommended compiler flags for GCC [0], for example, do not appear to catch the wrapping assignment in the above example code.

0: https://developers.redhat.com/blog/2018/03/21/compiler-and-l...

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

#237

Post by WGH_ »

ehvatum wrote: post #224
alerighi wrote: post #192

Earlier quoted context omitted.

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 com…

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

On the other hand, proper event-driven init system (instead of horrible shell scripts with all sorts of fragile "sleep"s and other hacks) sounds sexy for an embedded system. I sometimes get annoyed how home routers, NAS, etc. are slow to boot up

Though the embedded systems I refer to have much more than 16 MB of RAM, more like 128 and up.

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

#238

Post by jwilk »

wahern wrote: post #198
alerighi wrote: post #194

Earlier quoted context omitted.

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…

The Linux kernel doesn't have an actual path limit. Nor does Solaris. PATH_MAX is 4096 in glibc and musl libc because setting to it to something like INT_MAX or ULONG_MAX would break a lot of existing code that uses PATH_MAX to size buffers. (Though Solaris does define it as INT_MAX, IIRC.) OTOH, because of the lack of a hard limit there's also code that relies (if accidentally) on paths longer than PATH_MAX.

Linux does have a limit, at least for some system calls:

  $ strace -e trace=file perl -e 'open(FH, "

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

#239

Post by GoblinSlayer »

stjohnswarts wrote: post #170
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.

Good find thanks for sharing. And everyone at work gripes about me carrying the size around with a lot of my variables in the form of a struct. It's strictly a reminder to always be checking the size since I'm juggling with shotguns.

Do they even C? It's official ideology: a good programmer compensates shortcomings of the language.

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

#240

Post by magicalhippo »

paavohtl wrote: post #114
Already__Taken wrote: post #110

Earlier quoted context omitted.

Windows lifted that limit a few years ago

AFAIK the limit has been lifted since Windows NT (so since the 90s), but only if you use the obscure NT path prefix (\\?\).

Not that obscure, it's been mentioned on MSDN for every relevant operation since before 2000.
Post reply on HN