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

141–150 of 280 posts

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

#141

Post by mishac »

userbinator wrote: post #132

Our exploit requires approximately 5GB of memory and 1M inodes ...so basically 32-bit systems are totally unaffected (and I believe size_t and int are the same size there anyway), but I think bugs like this are easily prevented by simply imposing sane limits --- there is zero reason to even consider allowing a path more than a few K in length, and IMHO even that is overly generous. While I know there's a lot of hate…

> I personally haven't run into it as a developer

Clearly not a nodejs developer then! npm's insanely nested dependency graph caused me to hit the 260 character limit relatively regularly. (though this was several years ago, so maybe they have mitigations for that now)

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

#142

Post by pfraze »

mishac wrote: post #141
userbinator wrote: post #132

Our exploit requires approximately 5GB of memory and 1M inodes ...so basically 32-bit systems are totally unaffected (and I believe size_t and int are the same size there anyway), but I think bugs like this are easily prevented by simply imposing sane limits --- there is zero reason to even consider allowing a path more than a few K in length, and IMHO even that is overly generous. While I know there's a lot of hate…

> I personally haven't run into it as a developer Clearly not a nodejs developer then! npm's insanely nested dependency graph caused me to hit the 260 character limit relatively regularly. (though this was several years ago, so maybe they have mitigations for that now)

IIRC this is partly why node_modules moved to a flat structure

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

#143

Post by HanyouHottie »

derefr wrote: post #130
rocqua wrote: 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…

MSVC has this[1]. .NET code analyzers are also versioned[2].

[1]:https://docs.microsoft.com/en-us/cpp/error-messages/compiler... [2]:https://docs.microsoft.com/en-us/dotnet/fundamentals/code-an...

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

#145

Post by antoinealb »

derefr wrote: post #130
rocqua wrote: 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…

I think it might be more of an headache: what if somebody fixes a bug in an analyzer so that it catches things it used to miss ? Should it be a breaking change ?

Personally i would vote for "Wall with Werror" means no guarantee for your build.

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

#146

Post by usefulcat »

gruez wrote: post #3
Zababa wrote: post #2

> Unfortunately, this size_t is also passed to functions whose size argument is an int (a signed 32-bit integer), not a size_t. Is this the type of things that could be caught by a linter or strict compilation rules? This seems to be to be a failure of the type system.

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 rationale.. it's just annoying to have to resort to using pragmas to turn off -Wconversion whenever I need to assign to a bitfield.

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

#147

Post by kaba0 »

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…

Though one should mention that most languages can evolve and overcome some of their problems, eg. see PHP which used to be objectively a shitty language and nowadays it is somewhat usable - C underwent basically no improvements in that ridiculous timeframe. So it is not against the original creator but everyone responsible for the language since then.

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

#148

Post by kaba0 »

wyldfire wrote: post #44
airocker wrote: post #9

Can we not have one integer type in c that can grow like in js as required and become bigint if too big?

Yes, arbitrary precision integers could theoretically become a C language/library feature. But let's say that it gets proposed and accepted and it's integrated into popular compiler toolchains. The kernel wouldn't leverage it here or likely anywhere else because of its cost. A newly designed OS kernel could perhaps take on this kind of feature. This would be the kind of OS that could be formally verified and would be…

C doesn’t have the abstraction power to make anything with such a datatype.

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

#149

Post by jerf »

airocker wrote: post #131
jerf wrote: post #118

Earlier quoted context omitted.

We don't need arbitrary-sized integers; we need exceptions on overflow (or underflow, but I'll stick to overflow for the rest of this post) to be the default, or similar language features as appropriate. I for one am tired of the chicken & egg issue of "CPUs don't support efficient overflow checking because nobody uses it, so it's slow" and "Overflow checking is slow because the CPU doesn't support it, so nobody uses…

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 of code that operates this way. I'm sure it's only a matter of how many zeros belong in the 0.001%.) But we need this support to be available for code to be turn on easily and cheaply.

But what really boggles my mind, again given all the security work we've done, is that the reaction to this remains a combination of silence and "we can't do that!", when it seems to me the reaction ought to be "well duh jerf we all know that already." I don't get this. I don't get this attitude at all. This is a huge source of errors, a good fraction of which are security bugs, and nobody seems to care. Incomprehensible. This is, arguably, the number one thing that could be getting changed right now to fix security issues, and I just get slack-jawed "whaaaa?" in response to the idea.

One hundred plus one hundred is not negative fifty six! Here we are trying to hold together megabytes upon megabytes of security-critical code in a world where 100 + 100 = -56. Is it any wonder that writing any sort of code to maintain security invariants is tough in an environment where 100 + 100 = -56?

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

#150

Post by MauranKilom »

userbinator wrote: post #132

Our exploit requires approximately 5GB of memory and 1M inodes ...so basically 32-bit systems are totally unaffected (and I believe size_t and int are the same size there anyway), but I think bugs like this are easily prevented by simply imposing sane limits --- there is zero reason to even consider allowing a path more than a few K in length, and IMHO even that is overly generous. While I know there's a lot of hate…

We've had trouble (and had to occasionally shorten module names to something dumb like mdlWthVclsRmvd) because some part of some toolchain would create a path like

    C:/current/working/directory/that/is/reasonably/deep/testrun/YYYY_MM_DD_hh_mm_ss/code/moduleName/src/build/bin/../../../../../../outputs/moduleName/YYYY_MM_DD_hh_mm_ss/outputFolder/moduleName_testrun_results.txt
or some garbage like that (you get the picture). Yes, half the path was taken by descending into some directory that it went out of again straight away. Test runs would fail because of the 260 char limit unless we cut down the module name length. (Thankfully this did not need to be done in the code itself, just in the test run invocation.)
Post reply on HN