Linux: Vulnerabilities in nf_tables cause privilege escalation, information leak
lwn.net
lwn.net
https://nvd.nist.gov/vuln/detail/CVE-2022-1016
https://access.redhat.com/security/cve/CVE-2022-1015
https://access.redhat.com/security/cve/CVE-2022-1016
https://ubuntu.com/security/CVE-2022-1015
https://ubuntu.com/security/CVE-2022-1016
https://security-tracker.debian.org/tracker/CVE-2022-1015
https://security-tracker.debian.org/tracker/CVE-2022-1016
I just spent the whole weekend patching whatever the last kernel vuln was and had to plan around like 20 people's schedules. I thought Meltdown/Spectre was bad, this year is already feeling like that year in repeat.
15 years as a sysadmin, anyone have suggestions for my next career move? Thanks.
I made the switch to Technical Product Marketing after 15+ years doing linux sysadmin stuff. This might seem weird at first but all tech companies have complex products that they are trying to sell to a technical audience. Marketing needs technical folks embedded that can translate between the tech stack and marketing speak. You can probably 2x your sysadmin compensation quite easily and offers tons of career growth (developer relations, tons of conference speaker opportunities, become some industry expert, etc).
No idea about your skill set or area of expertise but here's an example from vmware [1]. Just search for "Technical Marketing". The job typically involves doing technical reviews of competitors, something you'll already do when deciding to choose a product as a sysadmin, reviewing internal marketing content to make sure people are telling the truth, doing talks/training, recording demos, interacting with PM/Eng about product releases, testing and writing about new releases, etc. If you like the technical side and don't mind teaching this can be a good transition. You basically leverage all the skills you've built over 15 years and apply them to something else quickly.
The kicker here is that you can just apply to companies where you already use their products and know them inside and out (giving you a massive advantage compared to other people applying). Say, you do tons of AWS stuff, well who better to work with marketing on the technical side then a sysadmin who breaths this stuff everyday, or maybe you're doing stuff on cisco switches [2], or maybe some netapp storage fabric expert [3], same thing. All these companies have technical roles in marketing that want you and it can range from mega corps to cool startups like GitLab [4].
[1] https://careers.vmware.com/main/jobs/R2204162?lang=en-us
[2] https://jobs.cisco.com/jobs/ProjectDetail/Technical-Marketin...
[3] https://jobs.netapp.com/job/Bangalore%2C-Karnataka-Technical...
[4] https://about.gitlab.com/job-families/marketing/technical-ma...
Is there a patch one can apply in the meantime? The RedHat suggested mitigation requires disabling functionality that is heavily depended on.
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.
I don't think it's the newly build stuff that companies are worried about. It's the old legacy stuff that's on life support that no one wants to modernise or maybe they cannot.
I guess what I'm getting at, is that sure if they design new things they will follow modern patterns but there is so many things that are not modern. They don't have the time or incentive to just go and rebuild all this stuff. There is zero benefit to them on a bottom line, unless there is some burning fire, a way they can extract more money, or save tons of money. So, they just keep them on life support and run in a keep the lights on mode until something happens. These are the systems all sysadmin's just wish went away and there's many of these types of things all over the place.
One of the big trends from the 2010s for cloud software was to cloudwash old stacks that really weren’t more than simply validated to not crash and burn on an EC2 instance, which is why the entire cloud native movement exists to differentiate greenfield cloud architecture services from cloudwashed ones.
Things can be pretty frustrating working with different vendors of different applications and competencies. People will be patching log4j issues for years to come, for example, and that’s probably easier to validate in aggregate than entire kernel upgrades for decrepit, unsupported distros like CentOS 5 that I still hear about being used.
Real life is more complicated, and even if the organisation willpower and politics are aligned in a way to _want_ to fix it, this takes a long time.
Chastising someone on HN because they own a system that probably wasn’t designed and might not have the power to fix seems at best, a little unfair.
I didn't chastise anyone.
Would it not just mean that you have more computers to update in your redundant/tolerant cluster?
Honestly, a kernel update has to be a routine, low effort, low stress task. It's a common event that should be seen as part of the normal operation of the system, not as some exceptional event that means someone has to work on the weekend.
Then there isn’t any stress to doing it, it’s routine and automated.
For bonus points you're also not babysitting manually provisioned servers but instead have your software installs automated. So any failure on a server or OS update isn't seen as a maintenance piece but rather just terminating the old server and letting your pipeline auto-build a new server. This is often referred to as "treating your servers as cattle rather than pets", though not everyone likes that analogy.
I'm keeping my eyes open on circus website careers pages. I reckon I'd have way fewer clowns to deal with if I was an actual clown car driver... :sigh:
No stress, (relative to what you are doing now).
You can hand off to another team at the end of your shift.
You got HR, perks, pension etc. You just gotta eat a bit of shit :)
Yes there is a ton of downsides too but look, you are a Linux admin you may as well sit back and use them skills for a while so you can de-stress and get your life back.
Not sure where you are based but there is a massive demand for Linux admins in Ireland (and probably Europe)
What is the fix? Surely they don't release this kind of info without a fix.
So bottom line - upgrade kernels to latest of your branch, if you're able.
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?
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.
There are tons of checked_add()_sub/_mul macros or functions floating around. At least in C++ one could override the global operators if needed.
(And if that’s the case, by now INTO will be a slow microcode implementation, with JO _trigger_into probably being much faster)
No Intel/AMD CPU supports INTO in 64-bit mode.
It is wise to compile any C/C++ program with options like:
"-fsanitize=undefined -fsanitize-undefined-trap-on-error"
(as for gcc) or whatever they are called by the used compiler.
In that case, the compiler will add instructions with the same effect as INTO, but with more overhead than it was needed in 32-bit Intel/AMD CPUs.
The execution time should be about the same for INTO and JO, both for the normal case, when both INTO and JO are ignored and for the error case, when JO is guaranteed to be mispredicted, so its long execution time added to the time needed to fetch and execute the following instructions required to match the effect of an INTO (e.g. saving state and a second not-predicted jump or call that might be needed to reach the actual exception handler) will also be about the same as what would have been needed by an INTO exception, if not longer.
And if you're really worried about size, "JNO 1f; INT xy; 1f:" 'with xy having to be system wide and well known, but it would only take 3 extra bytes (or just 2, if you HLT and the OS knows what JO/HLT combo means). The branch predictor will likely predict this as a no-take in any tight loop.
Other architectures, like IBM POWER, have much more powerful conditional trap instructions.
The 64-bit ARM ISA is the only other important architecture where integer overflow must also be done by combining a conditional jump either with a function call or with a supervisor call (i.e. the equivalent of INT).
It is true that if INTO would have never been defined in 8086, it would not have been a great loss, because it can be emulated, as you say.
Nevertheless, its deprecation by AMD cannot be a reason for praise. At the same time, they have also deprecated a few other instructions, which were a good choice, because they were much less useful. On the other hand there were a very large number of other instructions that could have been deprecated instead of INTO, which were much less useful than INTO, but they have been kept nevertheless.
It was pretty clear that INTO and BOUND were not included on the deprecated list based on their degree of usefulness but mainly because it was obvious that the CPU designers will be able to get away with this, because all the important software companies were habituated to compile their release versions by choosing to disable all run-time checks, so they will not complain about this omission.
If the software vendors would have ever been punished for choosing to omit the error checks, then they would have requested CPUs that still have good performance when the checks are enabled and the CPU designers would have been prodded to improve such features.
Nowadays, due to the hype about security flaws, the CPU vendors are introducing a large number of run-time checks, but most of them seem rather misguided, because in the attempt to protect against programming errors some of the methods used e.g. for limiting the targets of jumps also prevent the use of certain good implementation techniques for some programming language features.
Instead of the many dubious new "security" features of Intel/AMD and ARM CPUs, I would much prefer to see improvements in the efficiency of overflow checking and bounds checking, because these are checks that are required in any program, no matter how well it is written, while most of the new "security" features are mostly useful to avoid problems created by programmer mistakes.
I.e., sometimes you might want the check, but other times you certainly don't, and turning it off and on at the right times is too hard to get right. And, the ability to turn it on, even when it was never used, slowed everything down.
You would anyway need to be able express the choice in the languages used. If you had such a way, a compiler could insert extra instructions to check or to suppress checking where it is not wanted, but making such a choice wherever arithmetic happens would be a big burden to programmers already just barely hanging on.
It was removed because it was seldom used by Microsoft and by the other large companies which mattered, so the AMD and Intel designers took advantage of this bad habit of many programmers, in order to simplify their CPU design work.
It was seldom used because the programmers have always preferred to obtain the highest speed even with the risk of erroneous computations in seldom cases.
The reason is that a lower speed is noticed immediately, possibly leading to a lost sale, while occasional errors may be discovered after a long time and even when they are discovered, the programmers who have made this choice are not punished proportionally with the losses that might have been caused to the users, which in most cases are difficult to quantify anyway.
A normal policy is to always check for integer overflow, out-of-bounds accesses and so on. Such checks are provided by all decent compilers.
Only when performance problems are identified and if it is certain that there is no danger in omitting the checks, the checks should be omitted in the functions where this matters.
Selecting whether run-time checks must be done or not is very easy. You just need to use the appropriate sets of compiler flags for the 2 kinds of functions, those with enabled checks and those with disabled checks.
It is sad that the C tradition has imposed that the default compiler flags are with disabled checks, but that is not an acceptable excuse. Any C/C++ programmer should always enable the checks, unless there are good reasons to disable them.
If they do not do this, it is completely their fault and not the fault of the programming languages.
However the C/C++ standard libraries have the problem that they lack a good standard way of handling such exceptions (i.e. a better way than the UNIX signals). That means that if you do not want to abort the program in case of overflows or out-of-bounds accesses, it can be difficult to ensure a recovery after errors.
In fact harmless overflow is extremely common, and relied upon. Trapping by default, while it would would call attention to some bugs, would also turn many working programs into crashing programs.
Saturating arithmetic would sometimes produce better results.
When computing with modular numbers, you rely on the exact modular operations. That is not overflow.
There exists no "harmless overflow". The overflow of "signed integers" is an undefined operation in the C/C++ standard.
The actual behavior of integer overflow is determined by the compiling options. With any decent compiler, you may choose between 3 behaviors: trap on overflow, which aborts the program unless it is caught, display an error message and continue the execution with an undefined result of the overflown operation (typically with the purpose of also seeing other error mesages), or ignore the overflow and continue the execution with an undefined result of the overflown operation (the default option).
Relying in any way upon what happens on overflows (of "signed integers"), when choosing a compiling option that does not trap on overflow, is an unacceptable mistake, because what the program does is unpredictable.
Relying on what modular arithmetic does with "unsigned numbers" is correct, except that in most cases they are not really used as modular numbers, but the programmers expect that modular reduction will never happen. When it happens and it was not expected, it may cause similar problems like overflows, even if the result could have been predicted.
You are right that saturating arithmetic is the main alternative to trapping on overflow. It can be used in the same way as infinities are used with floating-point numbers when the overflow exception is masked.
Unfortunately, saturating arithmetic does not exist in the standard C/C++ languages. Therefore in C/C++ you may choose only between trapping on overflow and dangerous undefined behavior.
Ada does this correctly, and lets you choose between exception and wraparound. UB is not an option in the language spec, though you can turn off the checks as an optimization option in GNAT, or maybe turn it off at specific lines of code with a pragma.
Of course using straighjacket systems programming languages (as they put it) doesn't match hacker culture, so here we are.
In the Ariane 5 case, an ill-tuned and anyway unnecessary out-of-bounds check was compiled into the inertial platform firmware, causing a debug traceback to be dumped to the rocket gimbal controls, which interpreted the traceback as instructions to steer sideways. To be clear: without the trap, the payload would have been delivered unharmed. There was nothing useful that could be done about the out-of-bounds value during the actual launch, and they knew that when they built the system. Extra points for dumping debug details down a channel where it corrupted correct data.
Europeans I have mentioned this to considered what did happen a sensible outcome.
The code reuse in the project was pretty poor engineering, they reused code from a different project which had different flight paths and characteristics, and didn't test it.
The modern equivalent would be copying and pasting code from a completely different project, and then just shipping to production without testing it at all, even locally.
Note that Ada is being used for the Ariane 6.
Spacecraft failures that can be blamed on failings of a particular language are very rare. There was a planetary space probe that failed arguably because it was coded in Fortran.
Leaving in debug code, especially for an entire part of the launch that doesn't exist anymore by bringing in reused and untested code, seems like the real problem. I'm pretty sure integer overflow in this case would be undefined behavior, so you don't know what the compiler would do, especially since things were a lot more wild on the hardware side in 1996. Your point sounds like arguing that preferring Objective-C would prevent all those pesky `NullPointerException`s in Java since it allows sending messages to nil (null), but that's success by coincidence.
If you read the ESA's report [1], there were a lot of things which failed before you even get to the language. This software failure is the only one in the entire Ariane series of rockets. Considering that this is 1996, the list of languages to pick from was pretty slim, e.g. this predates C++ initial standardization (1998), `enum class` and other modern C++ features.
Even using just Ada 83 (of which 95, 2005, 2012, and 2022 succeeded and improved), I would argue that its forward looking features of preventing mixed mode arithmetic having properly typed checked enums and other features (like being strong typed) probably prevented a significant number of failures should other available languages at the time been used.
> The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values.
> o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.
The Ariane 5 disaster was implicit in the design. Without that built-in flaw, the Ariane 4 inertial platform would have worked correctly as-was, and the first Ariane 5 would have delivered its $half-billion payload successfully, instead of obliterating it.
There is no circumstance where dumping debug tracebacks down a control channel not prepared for that is ever correct. Period. Anyone suggesting otherwise is displaying their blinders.
We agree here.
Did you read the report?
> The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose.
> The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5.
> m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off.
> The reason for the three remaining variables, including the one denoting horizontal bias, being unprotected was that further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty.
> Ariane 4 should not produce such an acceleration
My point is that it's a velocity, not an acceleration and hence is physically impossible by the design and flight parameters on the Ariane 4. It's like saying an unsigned byte (8 bits) is okay for a speedometer for a minivan because >255 mph is outside the physical capabilities of the vehicle, but reusing that speedometer code for a fighter jet is not appropriate.
All code is written with these assumptions of value ranges, it's just a manner of how the language handles them, and whether that behavior is predictable (UB or not) or crashes when outside those bounds. A lot of C and C++ code is written with short/int/long without realizing that those are fuzzy boundaries (short <= int <= long) and without going to ensure sufficient sizes (e.g. uint32_t). Math code which doesn't account for this can produce wild and usually incorrect behavior.
When enabled, any value in Ada can throw a constraint check if violated, and it just makes it explicit. You're assuming that "Don't crash on overflow" is always a good thing based on a single case, there's a lot of systems, particularly mechanical ones, in which a broken sensor reporting a pegged sensor value would want an immediately halt to operation. Also in space applications, out of bounds values can arise from other conditions as well, such as cosmic rays flipping bits, in which a computer restart (relying on the redundant system) is the correct and expected behavior.
Well, yeah. The firmware had been designed for a quite different rocket, the Ariane 4: https://www.bugsnag.com/blog/bug-day-ariane-5-disaster
I don't know how this is really a mark against Ada, it's an issue that would only be discovered by human intervention or by running a simulation of the rocket.
It is not a mark against Ada, particularly, it is a mark against brain-dead insistence on overflow traps.
And, destroying a $half-billion payload because you insisted on leaving debugging apparatus in a production system would seem less obviously correct if the cost of the loss were deducted from your salary. So, people insisting it was a good result may be interpreted as expressing satisfaction with freedom from consequences of irresponsible behavior.
Have you seen how the C math library does error handling? It silently writes to errno. I can just imagine the runtime using the trap to do just that and continue as if nothing happened.
However all C/C++ compilers have options to detect and report or trap on all common errors, but few people use these compiling options, because of a usually baseless fear that they might reduce the performance more than acceptable.
In the cases when the performance is indeed too low for correct execution, the complaints should be directed to the CPU manufacturers who are guilty of this (by neglecting the architectural features needed for handling many kinds of exceptions, which were considered mandatory in older CPUs), instead of improving the performance of the programs by cheating, i.e. by omitting the error checks and by accepting that the programs may have horribly wrong behaviors in seldom cases.
In C++ you can throw an exception, and count on anybody who cares to act on it, resolving the conflict.
Another one would be bound, which eventually got dropped.
is a massive understatement…
That flag is not set by default in the new project templates for whatever reason. There's also an escape hatch, the unchecked keyword, for the rare cases where you need to overflow, e.g. when implementing hash tables.
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.
Also Singularity https://en.wikipedia.org/wiki/Singularity_(operating_system) and a few random attempts like SharpOs https://sourceforge.net/projects/sharpos/ and Cosmos.
An approach similar to what Meadows has taken with NuttX.
I haven't mentioned, because I expected it as a possible reply that Singularity wasn't 100% pure Sing#.
"
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).
I know. I wrote a Vim syntax hilighter for nftables.
And it is still failing.
Just imagine how much untested surface area is that for the `nft` CLI.
[1] - https://www.ssllabs.com/ssltest/analyze.html?d=egbert.net&hi...
Yeah, it’s also a JS-free website.
Migration to IPv6 is a work-in-progress.
Hurricane Electric ISP also has a weird login condition; they want you to create a second account so you can pass your IPv6 certification (first was for DNS/IPv4). So I am looking for a secondary DNS provider for IPv6.
That's great. I would love to see more JS-free sites and more lightweight sites.
You "don't really care" for a majority of users, based on what? TLS 1.2 is perfectly fine to use with strong ciphers. I salute your static website which is free of JS/cookies/bloat/external stuff (similar to my own blog), but at the same time you're actively sabotaging accessibility.
If they are astute in cybersecurity, they will be using other (and secured) browsers.
Also, I use Vanadium with JS disabled, which is already decently hardened imho. Yet, your choice of key exchange bars me from your site.
I am confused why even provide a link to a website which is configured to be inaccessible to most readers. May as well say "My work: an unpublished manuscript; message me for a copy".
And my website is for those who do do use the right tools.
> Also, my server decides the selection of algorithms in TLSv1.3, not the web browsers
SMH. Either use Caddy with an empty config file or follow Mozilla’s recommendation: https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&...
# modern configuration
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
- https://chromestatus.com/feature/5355238106071040
Chrome seems to support TLS 1.3 since v70, and I'm on 99.
There's only the 0-RTT/EarlyData as far as I can tell that may be messing things up, is it required for TLS 1.3? It's not enabled by default yet (still in dev?).
- https://chromestatus.com/feature/5447945241493504
- https://developers.cloudflare.com/ssl/edge-certificates/addi...
This guy also forces secp521r1 (the NSA curve which is impossible to implement correctly, is unsupported by Chrome and eventually by Firefox, and is dog slow) instead of using DJB’s x25519. This is what roleplaying as an SRE looks like.
https://bugzilla.mozilla.org/show_bug.cgi?id=1128792
so far, absolutely no justification for Google to drop P-521: https://bugzilla.mozilla.org/show_bug.cgi?id=1129077
https://security.stackexchange.com/questions/100991/why-is-s...
If you look at the telemetry for last actual Firefox release, only 8 (yes, eight!) out of 1.67 BILLION handshakes used a P-521 curve. This is a good indication that P-521 isn't needed, at least for certificates verified by web browsers.
because, TLSv1.3 negotiation capability is there.
My server dictates the selection, lest the client gets the sideway algo slip.
try it through your enterprise TLS transparent proxy.
also, no HE IPv6 tunnel.
https://android-developers.googleblog.com/2020/06/system-har...
https://msrc-blog.microsoft.com/2020/05/13/solving-uninitial...
Altough not a proper distro, Android's Linux kernel has been using clang for about 5 years now.
You can either do this as NET_CAP_ADMIN, or when you create your own user+network namespace as an unprivileged user. (which may not be allowed on your system either)
Perhaps Rust would have prevented this in the first place. But the entirety of Linux and the ancient UNIX philosophy is a giant labyrinth full of cobwebs riddled with hidden traps, landmines and trip-wires beyond exploring.
Must be the worlds largest and endless minesweeper game discovering all those C style vulnerabilities in the Linux kernel.
See: https://doc.rust-lang.org/book/ch03-02-data-types.html?highl...
Bugs occur in rust code too. It's not a silver bullet to fix all problems associated with software development. 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. Give it 40 years and people will be saying "rust bad, new thing good".
> it removes the last excuse of C/C++
Odd way of looking at it. I never ask myself "what _excuse_ can I give myself for using this tool"?
I'll continue using C and I don't need an excuse. I prefer C.
Outside of small hobbyist projects, the industry has an obligation to provide users with safe software.
1. Start new projects intended for production that have nontrivial security threats in C or C++
2. Not have a plan to categorically prevent memory safety errors in legacy codebases over the next decade or so, whether that be by transitioning to new languages or by applying rigorous hardware-level memory tracking
It's that it's parroted a thousand times every week.
Also, what is so bad about crashing bugs? To me, as a programmer, they're very good news. It means you found a bug, you (hopefully) have a crash/log to analyze, and more importantly it means the program didn't just silently continue executing and corrupt state/data without anyone knowing.
Sure, but that applies to any technology on any platform at any time.
Plenty of languages to chose from to replace C and its kind.
Maybe Zig is currently the closest thing to such a candidate, but it doesn’t even pretend to aim at this, andalign with the "C ABI as interoperation modus for foreign function interface" policy, like the rest[1] of programming languages.
Granted it is a matter for the market to be willing to move beyond it, and the OSes written in it, but the matter isn't technical per se, rather economical, political, human behaviours,...
Also I should note that NVidia, prefered to go with Ada/SPARK instead of Rust for their automotive firmware.
https://www.thomashelbing.com/en/whitepaper-templates-checkl...
If there's a significant improvement without critical downsides - I really hope they do. What's the reason not to?
It does nothing to help the situation. It's just complaining from people who won't be satisfied until all software is written entirely in rust. Why not contribute to the kernel and try to fix some bugs instead?
I don't care what memory safe language they choose, rust is just the obvious choice for this domain.
> Why not contribute to the kernel and try to fix some bugs instead?
Who says we don't? My company contributed a 0day to the Linux kernel just recently.
Maybe we're all saying "new thing better" because we're sick of people writing garbage software and making users unsafe? Maybe we actually know better than you?
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've never seen anything quite like the rust community. They're hell-bent on recruitment. More so than any other language platform I've seen. Personally, I'm just sick of it. It's fine if you don't feel the same way. I was just voicing my frustrations.
Usually we land on Rust only discussions, due to more active advocacy that should known better to avoid tiring the audience, or by defensive attittude from unsafe language folks that push back every single reference to write secure software as a sales pitch for Rust.
My point exactly.
> to write secure software as a sales pitch for Rust.
You guys already do a good job of writing the sales pitches. I'll leave that to you.
So maybe address that "You guys" to someone else.
It gets annoying to those of us who know how to do safe food prep without wearing gloves.
No. Of course not. It appears to be the most common solution and community matters, so I suspect it will end up being a dominant solution. But you can (mostly) solve this problem with completely orthogonal approaches. Getting all of your code to run on x86 with MTE enabled is another approach that prevents entire classes of problems.
I'm not a member of the Rust community. My actual work focuses more on the Log4j-style stuff than buffer overruns. But I really don't know what people who are upset about the state of memory safety can do to prevent the "ugh, here come the rust nerds" complaints other than simply never raising the problem - which obviously isn't the right approach.
10 years ago the C and C++ community complained about a different thing whenever memory safety came up. "UGH, stop talking about GCed languages. GC advocates are such aggressive recruiters." Now the complaints have just reoriented themselves.
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.
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.
Who said it was an argument? It's merely an observation of what I've witnessed here on HN: endless sentiment about rust and how everything should have been written in it.
The linux kernel was initially written 30+ years ago. Rust didn't exist. C did. Complaining about it being written in C does nothing to benefit anyone.
> I'd be very happy if in 40 years there's something better than Rust.
Me too.
For what it's worth, I agree. It's already written, so rewrite it yourself or use a Rust-based OS or work on Rust internals/specs in order to improve the language.
But I also believe that sometimes it can be a legitimate discussion. It can serve as a reminder that often these languages have footguns that even experienced developers that insist they can use C effectively will eventually fire off.
Now, in places where security didn't matter, it suddenly does. Thus, it's not about bad coding habits, but inadequate care in extending privileges to untrusted users. The code should have been cleaned up first.
The issue is still the code, it's just the impact that has changed.
> 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.
Well they should all stop what they're doing and rewrite everything in rust. Oh hang on, that's millions of lines of code.
Is not Unix philosophy, its legacy. And it predates rust.
It's like noticing Windows 9x's lack of security and stability on Windows 10 times. Absurd.
Heck, that book praised Mac OS back in the day, and just look what Mac OS has been turned into since Mac OS X.
Also, thanks to Unix philosphy my Fluxbox+Rox+Roxlib combo based "DE" it's much faster and featureful than most light desktops out there.
That's a con against RSI.
> 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.
It feels kind of like COVID in 2022. Obviously everywhere. Probably not going to hurt me? Could end my career.
Very unlikely.
Stick to good practices. If you are asked to do something that's bad for security, raise your objections in written form (email/tickets).
Security isn't only your responsibility; it's also the product manager's and the security team's responsibility.
All together this means that it's very hard for a company to convincingly blame a single developer for an incident. Maybe they fire you as a scapegoat, but that isn't very likely, and it should be far from career ending.
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.
If it does half of us would be jobless. Do reasonable choices, agree them with the team and the stakeholders. For extra safety do not accept jobs above your level of knowledge of security issues.
You'll make it. There will be bad times and there will be very long nights and weekends, and you'll probably have a few events in your life that will make you say "ok, I'm done" but you'll survive and make it through.
Try to be mindful of your mental and physical health as dealing with these issues can take a toll on you, but do know that you will survive and make it through.
But we’ll likely be fine. Just keep a healthy respect for security, keep learning and think through best practices.
1016 comes from an uninitialized value. 1015 is an int8 overflow and out-of-bounds access. Both are C footguns (though not exclusive to C). The latter arguably might not have happened under a stable/specified ABI.
1015:
Introduced in 5.12
Fixed in 6e1acfa387b9, 2022-03-17
In LTS, fixed in 5.10.109 and 5.15.32
Also, in 5.16.18 and 5.17.1
Introduced in v3.13-rc1
Fixed in 4c905f6740a3, 2022-03-17
Fixed in same point releases as above, plus 5.10.109
Doesn't look fixed in older LTSes yetOne of many reasons running as root inside a container is a bad idea.
Where are these admins who demand this configuration ?
EDIT: Apparently the Docker default capabilities don't allow CLONE_NEWUSER: https://opensource.com/business/15/3/docker-security-tuning
I didn't really think about this vector where you CLONE_NEWUSER in a container... definitely on systems that allow unprivileged users to do this it is a problem.
That's ubuntu.
Is that actually surveyed / quantified somewhere? I can't say I see that too often in professional environments and even home stuff sees a lot of standardisation around separate users (https://docs.linuxserver.io/general/understanding-puid-and-p...)
However in Kubernetes, by default, Docker's seccomp filter is disabled. At the moment you need to re-enable it on a pod by pod basis. There is work to allow a default cluster-wide setting but that isn't at GA yet.
People, sometimes, forget how sarcasm is a nice tool in criticism (tho here is just for the fun)