A remote code execution vulnerability in GNOME [LWN.net]

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:36 UTC (Tue) by rahulsundaram (subscriber, #21946)
In reply to: A remote code execution vulnerability in GNOME by rweikusat2
Parent article: A remote code execution vulnerability in GNOME

> I don't think the attitude behind this kind of "Just can't be arsed!"-coding can be fixed by doing it in a different programming language.

It may very well help. Languages like say Go or Rust have less legacy traps but also are typically used with optional linters like gosec and Clippy that warns about the common issues. I don't know whether C developers are usually doing this.

to post comments

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:57 UTC (Tue) by Wol (subscriber, #4433) [Link]

Well, when I set the coding standards for C programming, the rule was simple.

"I know we can't stop the compiler complaining, but you set the warning level to max and if you can't explain the warning away, it's a fatal error".

That was Microsoft C, and with warning level set to 4, we were calling a bought-in library and we couldn't suppress the "unused argument" warning. Anything else got fixed.

Cheers,
Wol

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 21:02 UTC (Tue) by proski (guest, #104) [Link] (1 responses)

I worked on C++ code in the past where we were making a great effort to catch possible issues in the code (~90% unit test coverage, code sanitizers, Valgrind, using multiple compilers with all warnings enabled), but I'm not sure we would catch that error unless testing the problematic value. With Rust, on the other hand, I'm confident that a non-exploitable panic is the worst thing we could get even without clippy.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 8:58 UTC (Wed) by NAR (subscriber, #1313) [Link]

The presence of atoi in itself is a code smell - and has been for the past 20 years.