Linux: Vulnerabilities in nf_tables cause privilege escalation, information leak (opens in new tab)

That's not an argument for sticking with the old programming language that apparently is impossible to use safely (if you think that you can use it safely, what makes you think that you are better than the all-star cast of C programmers that have contributed CVEs over the years?). There were better alternatives to C in the 80s, there most certainly are better alternatives to C these days. I'm so sick of the Uncle Bob school of thought that all that is needed for better software engineering is discipline. If we haven't managed to impose that discipline yet after five decades, why would we believe that it will magically appear in the future? My guess is that a programmer that had the requisite mythical discipline would gravitate to programming languages like Rust or Ada anyway, because that developer wouldn't mind tooling that helped with it.

> Bugs occur in rust code too. It's not a silver bullet to fix all problems associated with software development.

Not being a silver bullet doesn't mean it's not an enhancement.

Of the two bugs mentioned in this announcement, one is an uninitialized local variable, which is allowed in C but not allowed in many other languages (like Java or Rust). The other one is an implicit cast from an enum to a signed integer; in languages where this particular kind of cast must be explicit, not only it's easier to see when it's a signed integer, but also it's more probable that it would be cast to an unsigned integer instead.

> Each language will have its own set of issues and quirks. It's easy to pick on C because it's been around far longer than most things.

It's easy to pick on C not because it's been around for longer than most other popular programming languages, but because it has a larger amount of footguns. It's true that Rust has plenty of quirks of its own, but most of them will not cause security issues.

Bugs absolutely occur in memory-safe languages. Log4j was a thing.

But a huge number of exploitable vulnerabilities are completely prevented by memory-safe languages. We've spent decades trying like hell to come up with other solutions to prevent these kinds of bugs in languages like C and utterly failed. Nobody knows how to write C or C++ programs of any meaningful scale free from memory safety errors without calling for total rewrites and ballooning budgets by 50x.

> Give it 40 years and people will be saying "rust bad, new thing good".

Of course. Rust will have systemic problems and some new thing will mitigate those problems. This is a good thing, not a bad thing. Why should there be any expectation that a language be the desired language for engineering projects until the end of time?

I'm starting to get sick of the neverending sentiment that Rust is the only option to write secure software, and any remark for security gets dismissed as Rust sales pitch.

Plenty of languages to chose from to replace C and its kind.

while rust probably wouldn't have caught this bug, it is worth noting that the class is memory bugs C and C++ have are especially pernicious. bugs caused by manual memory allocation in these languages are often highly exploitable, and come from a common and necessary part of the language. As a result you end up with somewhere around 70% of security vulnerabilities being caused by a feature that just doesn't exist in other languages. the reason Rust gets so much hype is that it removes the last excuse of C/C++ (GC time).

> Give it 40 years and people will be saying "rust bad, new thing good".

Why is this an argument? Yeah, personally, I'd be very happy if in 40 years there's something better than Rust. It's been a solid few decades of C prominence, and moving from lang to lang should of course not be something that happens every few years. But on the scale of 40 years? I'd hope we aren't all still using something made today in 40 years, let alone a few years old.

Rust is good and C is bad though.

> Bugs occur in rust code too.

Generally speaking, not these ones.

> It's not a silver bullet to fix all problems associated with software development.

No one said otherwise.

> Each language will have its own set of issues and quirks.

But not memory safety ones.

> It's easy to pick on C because it's been around far longer than most things

Not at all. Lots of languages existed before C that had improved safety. It's easy to pick on C because, with regards to memory safety, it's awful.

There are ways to manage the risk of buffer overflow in C without changing the language, but C programmers don't want to do it, because traditionally they believe they need to be brave and do it the hard way.

> Give it 40 years and people will be saying "rust bad, new thing good".

If there's a significant improvement without critical downsides - I really hope they do. What's the reason not to?

This isn't exactly true. Rust doesn't include such checks when compiled in '--release' mode. And Rust provides plenty of methods to make the programmer's intent clear and perform 'safer' arithmetic ops.

See: https://doc.rust-lang.org/book/ch03-02-data-types.html?highl...

Oh, it is UNIX philosophy alright, given that C was created to make UNIX portable, and the security best practices were disregarded, offloaded into lint, that most people keep ignoring.

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

https://www.bell-labs.com/usr/dmr/www/chist.html

> Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

-- C.A.R Hoare on his Turing award speech in 1981.

Uninitialized stack is just negligence. Compilers can trivially initialize all stack variables. Yes, it's slower, but Android and Windows already chose slow but secure default. Linux just decided to be insecure.

Unix philosophy has plenty of problems: https://web.mit.edu/~simsong/www/ugh.pdf

This greatly depends on the organisations size and if you're on-prem vs cloud. If you have a small-medium startup with a single product and a fairly simple architecture in AWS this might make sense. But, if you're a bank or something with 1000's of applications, 100k+ servers on-prem, and a global footprint with availability requirements this is a vastly different story.

These are obviously two extremes but you can see there is tons of stuff in the middle two. The larger folks are the ones that are stressed 24/7 even when they have the tools to do it.

You just made a bunch of assumptions about what their system is and does.

The oss-security message has the commit hashes, these links (aside from the NVD, which seems to just lack information for the moment) are is only needed to figure out when their backports hit your distro kernel. The answer to that seems to be “not yet” for all the liked distros, which is weird.

I do not see a mitigation mentioned, but the impact of both of these seems to be limited to users with the ability to install nftables bytecode, so it seems having user namespaces disabled (if you don’t need them) would make this irrelevant?

Yes, this confuses me as well. It would be good to know what kind of fixes the grandparent has applied.

At least point 1 is solved now.

Which on x86, one could trap on overflow. That is one of those legacy options people complain about because they aren't used by C. I'm not sure that is as easy on Arm/etc because IIRC there isn't an integer overflow exception.

For whatever reason most newer languages (say rust) don't actually solve this problem either. They could diverge from the normal and do saturating (which arm does have) ints, or throw exceptions on overflow/underflow, but they don't because that would be to hard when they have to manually check overflow on each operation because its not a common feature of many processor arches.

edit: although LEA is one of the instructions which avoids flags updates, so even if you wanted to trap it probably wouldn't.

> not free from problems

is a massive understatement…

> You can't use c# for kernel development of course

Midori team kind of disagreed with that, and most of System C# features keep landing on regular C# a bit per version, but I digress.

-fsanitize=signed-integer-overflow produces rather decent code with GCC.

Read the report closer, its a buffer overflow because the buffer overflow check failed due to:

"

Effectively this implies that the compiler is free to emit code that operates on `reg` as if it were a 32-bit value. If this is the case (and it is on the kernel I tested), a user can forge an expression register value that will overflow upon multiplication with `NFT_REG32_SIZE` (4) and upon addition with `len`, will be a value smaller than `sizeof_field(struct nft_regs, data)` (0x50). Once this check passes, the least significant byte of `reg` can still contain a value that will index outside of the bounds of the `struct nft_regs regs` that it will later be used with. "

Which is the classic way to exploit integer overflow to bypass buffer checks (i've personally written code like this, which thankfully was caught before it got this far).

> Security isn't only your responsibility

This.

As a developer, your security-aligned goals should include code review, readable/auditable code, configuration options that support testing/QA, features that operate on a principle of least surprise to the user, and other things like these. Security is ultimately a blended practice.

Android and Windows do take that hit.

https://android-developers.googleblog.com/2020/06/system-har...

https://msrc-blog.microsoft.com/2020/05/13/solving-uninitial...

As far as I can find that flag seems to be clang specific? Which distros even use clang? Also since the Kernel is not pure C not all safety options are safe, at one point a few distros enabled stack overflow protection, only to end up with a kernel that randomly corrupted application stacks.

Yeesh.

Most containers are going to block unshare() via seccomp, no?

They have a good cert rating but ipv6 is not responding [1] and some clients will be denied based on cipher policy. I would be surprised if that applied to Chrome but one can always check. The DNS entry for ipv6 should be removed if not used.

[1] - https://www.ssllabs.com/ssltest/analyze.html?d=egbert.net&hi...

It is ok until new hardware is purchased that won’t run on the older kernels. For pure VM stuff, the 2.6.32 s fine (Go supports it without patches) but the newer kernels have much better scheduler and other cpu optimizations. I saw about a 25% efficiency gain from upgrading to 4 series kernels after specter etc.