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

251–260 of 280 posts

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

#251

Post by derefr »

wheybags wrote: post #174
derefr wrote: post #130

Earlier quoted context omitted.

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

The real solution: leave Werror off by default, activate it only during CI builds

That's even worse, because then an upgrade to the compiler in the managed CI runner (e.g. Github Actions') base-image will translate to the same version of the code failing where it previously succeeded, with nobody sure why.

At least with -Werror on at all times, devs will tend to upgrade before the very-stable CI environment does, and thereby catch the problem at development time (usually less time-pressure) rather than release-cutting time (usually more time-pressure, esp. if the release is a hotfix.)

-----

Mind you, it does work to enable -Werror only in CI, if you lock your CI environment / compiler Docker image / etc. to a specific stable version, and treat that as the thing to re-lock in place of the "error-check suite snapshot version."

This has the disadvantage, though, that you can't take advantage of newly-stable/newly-unstable language features, or of newly-introduced compiler optimizations, without biting the bullet and taking on the work of fixing the errors introduced by re-locking the base-image.

With a separate flag for locking down the error-check-suite snapshot version, you could continue to upgrade the compiler — and thereby get access to new features / optimizations — while staying on a particular build regression "scope."

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

#252

Post by samus »

tptacek wrote: post #31
McGlockenshire wrote: post #30

Earlier quoted context omitted.

Pulling this attack off requires enough access to the machine to either run the unprivileged commands needed to create the exploit condition or to upload a binary/script that runs unprivileged that in turn creates the exploit condition. If the attacker already has that level of unauthorized access, you're already doomed.

Attacks like this break multitenant computing environments. It's not a threat to your desktop computer or your phone. But it can be a very big deal for hosting environments. It also breaks sandboxing. To whatever extent you're trying to run programs that are somehow jailed, so you can download and run them without worrying about them taking over your system, kernel LPEs break those assurances.

Android also uses user accounts (one per app) to enforce its security model. Is that what you refer to with sandboxing?

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

#253

Post by samus »

snvzz wrote: post #129

$ ls -l /boot/vmlinuz-linux -rw-r--r-- 1 root root 9464864 Jul 16 12:59 /boot/vmlinuz-linux That's over 9MB, running in supervisor mode. 2021, and people are still surprised every time a kernel bug with security implications is found. Maybe it is time to look at different OS designs. Large companies such as Google (Fuchsia) or Huawei (HarmonyOS) have begun to pick up on this.

Most of it is drivers though, and stuff that is pretty much required to be there unless one's pasttime (or dayjob) is to tailor and harden kernels.

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

#254

Post by lazide »

BoorishBears wrote: post #249
opheliate wrote: post #236

Earlier quoted context omitted.

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

Ah yes, of course the goalpost was "you need to customize your settings to catch it" above. Now that the default in the most beginner friendly of IDEs catches it, the goalpost is "my pet source of customization designed with C++98 in mind doesn't catch this" Of course, even your pet source of customization caught up: https://developers.redhat.com/blog/2021/04/06/get-started-wi...

If said beginning friendly IDE is used by only a couple percent of the ecosystem, it seems disingenuous to use it as proof this isn't a problem in this context?

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

#255

Post by nextaccountic »

thayne wrote: post #217
stjohnswarts wrote: post #170

Earlier quoted context omitted.

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.

The fact that c doesn't have a native concept of an array with length and strings usually use a null byte to determine the end is, IMO c's biggest failing, and it's worst legacy on the wider software world.

This and having any pointer implicitly be nullable

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

#256

Post by BoorishBears »

lazide wrote: post #254
BoorishBears wrote: post #249

Earlier quoted context omitted.

Ah yes, of course the goalpost was "you need to customize your settings to catch it" above. Now that the default in the most beginner friendly of IDEs catches it, the goalpost is "my pet source of customization designed with C++98 in mind doesn't catch this" Of course, even your pet source of customization caught up: https://developers.redhat.com/blog/2021/04/06/get-started-wi...

If said beginning friendly IDE is used by only a couple percent of the ecosystem, it seems disingenuous to use it as proof this isn't a problem in this context?

Ok so we're going to keep shifting the goalposts, now it's "there aren't enough beginners relative to total usage so beginner friendly IDE isn't enough"...

I mean MSVS uses Clang-tidy too, Clang-tidy integrates style guides provided by Mozilla and Google.

Most C++ Google projects have clang-tidy configs.

Clang-tidy is literally table-stakes for modern C++ tooling.

Github shows 970,000 commits related to setting up clang-tidy

But uh, yeah, let's see where the goalpost skitters to next.

-

The irony is I said above, C++ has enough footguns without sticking your fingers in your ears and ignoring boring, easy to setup, widely well known and well used tooling.

But in the war against C++ no stone must be left unturned.

C++ is a tiny fraction of all the code I've written in my life but it irks me to no end that people can't deal with the idea that language safety can improve, that tooling can be considered part of that safety. Or rather they can... unless they're talking about C/C++

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

#257

Post by stjohnswarts »

GoblinSlayer wrote: post #239
stjohnswarts wrote: post #170

Earlier quoted context omitted.

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.

They seem to be all about the conciseness :) . We have gigabytes of memory, a size parameter isn't going to make a difference haha. The allow me my little idiosyncrasies though so I can't complain.

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

#258

Post by baby »

jamincan wrote: post #248
baby wrote: post #49

Earlier quoted context omitted.

I wish clippy had a lint against downcasts specifically. I aso like that rust has no “int” type

It does, you just need to enable it. There are a bunch of other cast-related lints as well that are allow by default. https://rust-lang.github.io/rust-clippy/v0.0.212/#cast_possi...

Oh wow, didn’t know about that one. Is this new?

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

#259

Post by opheliate »

BoorishBears wrote: post #249
opheliate wrote: post #236

Earlier quoted context omitted.

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

Ah yes, of course the goalpost was "you need to customize your settings to catch it" above. Now that the default in the most beginner friendly of IDEs catches it, the goalpost is "my pet source of customization designed with C++98 in mind doesn't catch this" Of course, even your pet source of customization caught up: https://developers.redhat.com/blog/2021/04/06/get-started-wi...

If by "caught up", you mean talked about clang-tidy in a separate post, which is definitely not a GCC compiler flag, then sure.

The goalpost, since you're insistent on being explicit about it, was whether a C/C++ compiler "with reasonable flags" will catch the implicit wrap. GCC is a very popular compiler, and to be honest, I'm still not sure how to get it to warn on the above code, if doing so is possible.

Edit: Just read the rest of the thread, it's -Wconversion, which I suppose makes sense. Ignore me, point taken.

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

#260

Post by snvzz »

samus wrote: post #253
snvzz wrote: post #129

$ ls -l /boot/vmlinuz-linux -rw-r--r-- 1 root root 9464864 Jul 16 12:59 /boot/vmlinuz-linux That's over 9MB, running in supervisor mode. 2021, and people are still surprised every time a kernel bug with security implications is found. Maybe it is time to look at different OS designs. Large companies such as Google (Fuchsia) or Huawei (HarmonyOS) have begun to pick up on this.

Most of it is drivers though, and stuff that is pretty much required to be there unless one's pasttime (or dayjob) is to tailor and harden kernels.

There are architectural ways to avoid this problem.

Making the kernel as small as possible, and having components and drivers run unprivileged is the primary way to achieve this.

Some real examples that do this: Minix3, Haiku, Genode, Fuchsia, Harmony.

Post reply on HN