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

Re:size_t-to-int vulnerability in Linux’s filesystem layer by userbinator on Tuesday July 20, 2021 @03:46PM (#27898341)

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 for Windows' traditional 260-char limit, I personally haven't run into it as a developer except by accident (e.g. runaway recursion) and it's very comforting to know that the limit is there so code will fail before it consumes the disk or memory entirely.

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by mishac on Tuesday July 20, 2021 @04:02PM (#27898538)

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

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by pfraze on Tuesday July 20, 2021 @04:04PM (#27898571)

IIRC this is partly why node_modules moved to a flat structure

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by MauranKilom on Tuesday July 20, 2021 @04:23PM (#27898803)

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

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by saagarjha on Tuesday July 20, 2021 @05:04PM (#27899304)

> I think bugs like this are easily prevented by simply imposing sane limits

In general, no. Attackers are clever and can usually find their way around arbitrary limits when a bug exists. Sometimes such a restriction might stop them, but more often than not they’ll bypass it some other way.

[ Parent | on HN ]