Microsoft details critical vulnerability in ChromeOS:
Microsoft finds critical hole in operating system that for once isn't Windows Oh wow, get a load of Google using strcpy() all wrong – strcpy! Haha, you'll never ever catch us doing that
Microsoft has described a severe ChromeOS security vulnerability that one of its researchers reported to Google in late April.
The bug was promptly fixed and, about a month later, merged in ChromeOS code then released on June 15, 2022 and detailed by Redmond in a report released on Friday.
Microsoft's write-up is noteworthy both for the severity (9.8 out of 10) of the bug and for flipping of the script – it has tended to be Google, particularly its Project Zero group, that calls attention to bugs in Microsoft software.
At least as far back as 2010, Google security researchers made a habit of disclosing bugs in software from Microsoft and other vendors after typically 90 days – even if a patch had not been released – in the interest of forcing companies to respond to security flaws more quickly.
[...] The ChromeOS memory corruption vulnerability – CVE-2022-2587 – was particularly severe. As Jonathan Bar Or, a member of the Microsoft 365 Defender research team, explains in his post, the problem follows from the use of D-Bus, an Inter-Process-Communication (IPC) mechanism used in Linux.
A D-Bus service called org.chromium.cras (for ChromiumOS Audio Server) provides a way to route audio to newly added peripherals like USB speakers and Bluetooth headsets. The service includes a function called SetPlayerIdentity, which accepts a string argument called identity as its input. And the function's C code calls out to strcpy in the standard library. Yes, strcpy, which is a dangerous function.
"To the experienced security engineer, the mention of the strcpy function immediately raises red flags," explains Jonathan Bar Or. "The strcpy function is known to cause various memory corruption vulnerabilities since it doesn't perform any bounds check and is therefore considered unsafe.
[...] Bar Or already received thanks from Google's Vulnerability Rewards Program, which in June awarded him $25,000 for the responsible disclosure of the bug.
(Score: 2, Funny) by Anonymous Coward on Thursday August 25 2022, @01:58PM (8 children)
So how the fuck does this sort of thing still keep happening? The experienced ones retire and they let the noobs write this stuff?
(Score: 4, Interesting) by RamiK on Thursday August 25 2022, @03:11PM (5 children)
Because they're not security engineers? The primary concerns of system programmers are product features to implement and deadlines to meet. Security is an afterthought. Only way to avoid this specific class of bugs is to use languages that default on bound checks and make unsafe string and pointer work is an explicit exception. Otherwise, you're just asking for it.
compiling...
(Score: 4, Funny) by Sourcery42 on Thursday August 25 2022, @04:02PM (3 children)
Right, sort of like this https://xkcd.com/292/ [xkcd.com]
(Score: 2) by RamiK on Thursday August 25 2022, @07:15PM (2 children)
Mind you, writing a goto instead of re-fracturing takes a deliberate choice to be lazy. However, not doing a bound check is simply normal C workflow that comes from normal, human error level forgetfulness.
compiling...
(Score: 2) by hendrikboom on Thursday August 25 2022, @11:15PM (1 child)
There are situations where a go to is the simplest and cleanest way to code something.
Those situations are rare.
Such as an extremely complicated recursive search. When yo find the damn thing, you write it to a global variable and go to eureka!
-- hendrik
(Score: 2) by RamiK on Friday August 26 2022, @12:19AM
The problem with recursive searches as an example for goto is that:
1. They're often embarrassingly parallel problems that should be done with CSP threads / coroutines where gotos and globals aren't used.
2. Having different exits to the functions will damage the ability of the decoder to speculate and pipeline.
Admittedly though, gotos will sometimes have a clear semantic advantage as an exit point for deep nested heuristics.
compiling...
(Score: 3, Funny) by JoeMerchant on Thursday August 25 2022, @06:45PM
This is why we open source... because stuff happens and the author and their friends don't always catch it.
More eyes can only be better, if anybody cares enough to scrutinize your code: welcome it.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 1) by crotherm on Thursday August 25 2022, @06:37PM
I laughed when I saw "strcpy". For some reason it reminded me of my first C book not K&R, some red book, Learning C or some such. No mention of system(2) calls, nor really unix for that matter. Turbo C FTW!
(Score: 2) by darkfeline on Friday August 26 2022, @12:54AM
Because each new human has to be trained from scratch. All of the wisdom and knowledge that a senior engineer may have, every single programmer would have to learn. And the amount of that knowledge never stops increasing. And programmer are expected to work while learning.
You would think we would carefully construct abstractions to minimize the gotchas. But these abstractions are designed by programmers who were still learning.
That's also we end up with regressions in social knowledge, like how we discovered that static type checking was a good idea, and promptly forgot about for a couple of generations only to rediscover it.
Join the SDF Public Access UNIX System today!