After reportedly dragging its feet, BlackBerry admits, yes, QNX in cars, equipment suffers from BadAlloc bug
- Reference: 1629336900
- News link: https://www.theregister.co.uk/2021/08/19/blackberry_qnxrtos_badalloc/
- Source link:
BlackBerry QNX Software Development Platform (SDP) version 6.5.0SP1 and earlier, QNX OS for Medical 1.1 and earlier, and QNX OS for Safety 1.0.1 are affected by an integer overflow vulnerability in the calloc() function of the C runtime library.
The flaw, identified as CVE-2021-22156 with a CVSS (severity) score of 9.0, is part of the far-reaching collection of programming blunders Microsoft dubbed BadAlloc and [3]disclosed in late April, 2021.
[4]
BlackBerry, [5]according to Politico , initially denied that its products contained one or more BadAlloc-class bugs, and subsequently resisted making a public announcement due to the difficulty of contacting all the manufacturers and other organizations affected.
[6]
[7]
The Register asked BlackBerry to explain the four-month disclosure delay and we've not heard back. We were, however, heartened to read BlackBerry's assertion that it "takes its critical role in other companies' embedded software supply chains with the utmost seriousness."
"BlackBerry is aware of this matter and can confirm that it does not impact current or recent versions of the QNX RTOS, but rather versions dating from 2012 and earlier," the company [8]said in a statement, adding that all potentially affected customers have been notified.
[9]BadAlloc: Microsoft looked at memory allocation code in tons of devices and found this one common security flaw
[10]Blackberry Cylance's consumer antivirus product won't work with macOS Big Sur until end of January
[11]BlackBerry says it’s virtualised macOS for M1 on an x86 CPU
[12]Unihertz Titan Pocket: Like asking Mum for a BlackBerry and she tells you 'but we've got a BlackBerry at home'
On the bright side, the US Cybersecurity and Infrastructure Agency (CISA) said it isn't aware of active exploitation of this particular vulnerability. At the same time, the agency acknowledged that an attacker with network access could exploit this flaw remotely if a vulnerable device is exposed to the internet.
"Exploitation of this vulnerability could lead to a denial-of-service condition or arbitrary code execution in affected devices," CISA [13]said in its alert.
[14]
The US cybersecurity agency observed that successful exploitation would require the attacker to have control over the parameters passed to calloc() , a memory allocation function, and to have the ability to control the memory accessed after the allocation. That's potentially achievable if, say, you're feeding data into a server-side program from a client. The client could trick the server into allocating too-small a space for the incoming information, allowing the client to subsequently overwrite the server program's data and hijack its operation.
For instance, a client program could tell an application it's about to send over a huge amount of data, causing the app to attempt to allocate space to hold that information. The buggy runtime library suffers an integer overflow, spilling from a large number to a small number of bytes to allocate. The allocator then returns a pointer to that minuscule memory space and the application would then try to fill the buffer with too much data from the client, overwriting necessary data and structures and allowing the attacker to overwrite pointers and other values in memory.
In this particular case, not only should the runtime library not overflow, applications should also not attempt wildly huge allocations as it's a sign that something is awry. Preventing either or both of those conditions would prevent exploitation.
[15]
BlackBerry said it has made patches available and is working with government and industry groups, noting that none of its customers have reported any impact from the code flaws. ®
Get our [16]Tech Resources
[1] https://support.blackberry.com/kb/articleDetail?articleNumber=000082334
[2] https://blackberry.qnx.com/en/company/about-qnx
[3] https://www.theregister.com/2021/04/29/microsoft_badalloc_iot/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YR3XdJ-g3mp08uefu7DQ1QAAAIg&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://www.politico.com/news/2021/08/17/blackberry-qnx-vulnerability-hackers-505649
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YR3XdJ-g3mp08uefu7DQ1QAAAIg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YR3XdJ-g3mp08uefu7DQ1QAAAIg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://www.blackberry.com/us/en/company/newsroom/press-releases/2021/blackberry-statement-on-our-public-notice-today-regarding-older-versions-of-qnx-operating-system
[9] https://www.theregister.com/2021/04/29/microsoft_badalloc_iot/
[10] https://www.theregister.com/2021/01/05/blackberry_cylance_antivirus_macos_big_sur/
[11] https://www.theregister.com/2021/05/20/mac_os_arm_on_x86/
[12] https://www.theregister.com/2021/05/20/unihertz_titan_pocket/
[13] https://us-cert.cisa.gov/ncas/alerts/aa21-229a
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YR3XdJ-g3mp08uefu7DQ1QAAAIg&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YR3XdJ-g3mp08uefu7DQ1QAAAIg&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://whitepapers.theregister.com/
Rust
I just knew if I left the reference to Rust in, we'd get dinged on it. I've just decided to take that sentence out rather than argue at length over it. We wrote at the end, regarding the BadAlloc hole in QNX:
"Such bugs explain why the Rust programming language, capable of memory-safety and type-safety, has become popular in recent years at companies like AWS, Google, and Microsoft."
Would Rust have prevented this specific bug? Maybe, depending on how it was used. You could use Rust's checked math operations that catch overflows, if you remember to use them; debug mode has them on by default. If the overflow is in a separate C lib, you're out of luck.
Is it a good idea to use Rust to avoid similar memory bugs - like what Google, AWS, and others are doing - yes. We mentioned Rust in a general sense because at least some devs look at bugs like BadAlloc, think, 'there but for the grace of God, go I' and opt to use Rust to minimize similar, related flaws to improve the quality of their shipped code.
C.
Re: Rust
rust isn't a panacea.
in my recent professional experience, the code that has has the most catastrophic bugs leaving core dumps and deleted databases has been rust. sure, this is an anecdote but my point is pointing at one small class of bugs that rust does solve and blithely generalizing chanting web scale, er, i mean rust at any class of bugs you can think of isn't correct.
i think rust brings some great safety that other languages haven't brought before, but saying it's a (memory) "safe" language and implying that all rust is safe to run in the general sense is linguistic substitution.
Re: Rust
I have doubts about this code being at a high enough level of abstraction for Rust to understand the bug. Memory management is just a pile of math until those numbers are finally cast into meaningful data structure references.
If I understand correctly, the memory safety in Rust comes primarily from static analysis mandated by the standard (outside of explicitly specified "unsafe blocks"). So if there is a memory allocation bug in a runtime library, no amount of safety built into the language is going to help right? After all, in the end the compiled code is still just pointers and offsets (with all the usual lack of safety guarantees).