[HN Gopher] BleedingTooth: Linux Bluetooth Zero-Click Remote Cod...
___________________________________________________________________
BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution
Author : ndrake
Score : 198 points
Date : 2021-04-07 16:06 UTC (6 hours ago)
(HTM) web link (google.github.io)
(TXT) w3m dump (google.github.io)
| ndrake wrote:
| PoC: https://github.com/google/security-
| research/tree/master/pocs...
| 1-6 wrote:
| Sometimes I wonder if driver support such as Wi-Fi on FreeBSD is
| terrible by design. That OS has almost no attack surface.
| 1-6 wrote:
| FreeBSD users sit back and laugh. Bluetooth? Wifi? Hah!
| mnd999 wrote:
| FreeBSD has Bluetooth in netgraph last time I looked. It's
| not compatible with much.
| josephg wrote:
| And wifi. I have a little home server running FreeBSD, with
| an intel skylake processor from a few years ago. Wifi works
| out of the box. I haven't tried Bluetooth but for my
| hardware, driver support has been fantastic.
| rollcat wrote:
| OpenBSD 5.6 (~6 years ago) removed the Bluetooth stack
| altogether, due to security/maintainability concerns, so yeah,
| pretty much.
| r1ch wrote:
| I'm curious how the "BadChoice" vulnerability did not get picked
| up by a static analyzer. Only initializing part of a structure
| should be very easy to catch.
| fulafel wrote:
| I wonder what effect self selection bias has in people who end up
| writing hand crafted complex parsing code in C for untrusted data
| in ring 0. You either have to believe that it's doable to get
| right or that it doesn't matter much if you don't, or "it's not
| my worry".
| ptsneves wrote:
| What are you trying to imply? That you have an equivalently
| useful and featured kernel in a safe language? Do you have a
| similarly featured Bluetooth stack in a "memory managed"
| language? Why are all OSes wrong?
|
| I apologize the readers for the rant but this whataboutism is
| so demeaning of the multitude of very inteligent people working
| in the field, and creates negative valued divides between the
| low level people and the userspace/web people with huge mutual
| distrust as shown in the parent and in mine.
| Aachen wrote:
| Dumb question (not a kernel or C developer): can't you call
| into code compiled from a memory safe language, like in a
| shared object file?
| loeg wrote:
| Yeah, and we're slowly slowly moving towards that model.
| One barrier is that some safe languages, like Rust, support
| far fewer target platforms than the Linux kernel does.
| There are C compilers for everything, but only a few Rust
| backends.
|
| Something similar to Wuffs[0] (posted on HN very recently),
| which compiles down to C, might be a good compromise
| between portability and safe languages. (There may be some
| contorted way to have Rust emit C, too.)
|
| [0]: https://github.com/google/wuffs
| pjmlp wrote:
| Definitely, for example check how to make Go .so libraries.
|
| https://medium.com/swlh/build-and-use-go-packages-as-c-
| libra...
|
| Naturally the runtime also comes along, but that is another
| matter.
| howinteresting wrote:
| Well, Android's Bluetooth stack is being rewritten in Rust so
| you probably can go pretty far in memory-safe languages
| (though of course Rust isn't a managed language, just a safe
| one).
| pjmlp wrote:
| Do you know C.A.Hoare?
|
| I advise you to read his Turing award speech from 1981.
| snikeris wrote:
| https://www.cs.fsu.edu/~engelen/courses/COP4610/hoare.pdf
| rubatuga wrote:
| its called a microkernel
| aidenn0 wrote:
| There are plenty of tools designed to help you write parsers
| that compile down to C. Alternatively there is the
| microkernel approach. Either one (or both) would satisfy GP's
| implication that hand-written C parsers in ring 0 are bad.
| athrowaway3z wrote:
| // quick hack, fix later
|
| { .... }
| anthk wrote:
| Not a valid C comment.
| nitrogen wrote:
| Double slash single-line comments are valid C99 and later.
| aasasd wrote:
| Look, it's 2020s. I'm getting put to sleep by stuff like this.
| You gotta amp the names up to 'Genital Grinder' or 'Vomited Anal
| Tract' if you want people to pay attention.
| BoardsOfCanada wrote:
| At least they didn't register a domain for it.
| nimbius wrote:
| dont forget its gotta have a vector graphic mascot and a custom
| TLD from a design team of MFA students. if the disclosure page
| doesnt take over my mouse like a new iPhone release website and
| include a youtube video i just cant be bothered.
| hyper_reality wrote:
| Reminds me of this from last week:
| https://catinthehatattack.com/
| aasasd wrote:
| Pfah, all the _graphic_ stuff you 'd want was done ages ago:
| https://img.discogs.com/x-gix4VLRA0rKQTfSf4lx6HKeMw=/fit-
| in/...
| formerly_proven wrote:
| "Blue Death spreads remote code execution like warm butter on a
| french toast"
| aasasd wrote:
| _The virus spreads in an instant,_
|
| _Your holes are its seducing._
|
| _It slays from a distance,_
|
| _You 're on the list for_
|
| _E-XE-CU-TION_
|
| _GAAAAAARRRRRRRGH!!!_
| throwaway889900 wrote:
| How about "ShitEatingGrin" or "AphexTwinAlbumCover"?
| neals wrote:
| Best I can do is Poopy Dentures.
| aasasd wrote:
| Well, there's always _vagina dentata_.
| not1ofU wrote:
| Poo-tooth?
| everdrive wrote:
| My decision not to have Bluetooth pays off again!
| orblivion wrote:
| So, tl; dr upgrade our kernels? Or is there more?
|
| (This would be useful to have on Google's site here, but I
| understand if it's supposed to be for academic audiences)
| mjg59 wrote:
| What was notable in this case was that Google disclosed this
| issue to Intel, and Intel then took responsibility for public
| disclosure. Intel then proceeded to mail patches to public trees
| without flagging them as having any security relevance, posted a
| public disclosure despite the patches only being in pre-release
| kernels and claimed that affected users should upgrade to 5.9
| (which had just been released) which absolutely did not have the
| patches fixed.
|
| Coordinating disclosure around security issues is hard,
| especially with a project like Linux where you have an extremely
| intricate mixture of long-term support kernels, vendor trees and
| distributions to deal with. Companies who maintain security-
| critical components really need to ensure that everyone knows how
| to approach this correctly, otherwise we end up with situations
| like this where the disclosure process actually increased the
| associated risks.
|
| (I was part of Google security during the timeline included in
| this post, but wasn't involved with or aware of this
| vulnerability)
| nimbius wrote:
| oof.
|
| from the guys who brought you "the spectre patch in the kernel
| thats disabled by default" and "ignore your doubts,
| hyperthreading is still safe" comes "the incredible patch built
| solely around shareholder confidence and breakroom
| communication"
|
| EDIT: spectre, not meltdown. oops.
|
| https://www.theregister.com/2018/11/20/linux_kernel_spectre_...
| hansendc wrote:
| > "the meltdown patch in the kernel thats disabled by
| default"
|
| I'm not sure to what you are referring to here.
|
| I was one of the people who worked on the Linux PTI
| implementation that mitigated Meltdown. My memory is not
| perfect, but I honestly don't know what you're referring to.
| Snild wrote:
| I'm guessing they're referring to Linus' ranting on Intel
| here: https://lore.kernel.org/lkml/CA+55aFwOkH8RH12Dzs=hT3e
| 7eS3Ckz...
|
| > The whole IBRS_ALL feature to me very clearly says "Intel
| is not serious about this, we'll have a ugly hack that will
| be so expensive that we don't want to enable it by default,
| because that would look bad in benchmarks".
| qwertox wrote:
| To me it feels like we owe Google a lot for what they are doing
| to find security vulnerabilities. Did companies do stuff like
| this before Google's Project Zero?
| varispeed wrote:
| It's like Intel is releasing the same CPUs with new boxes and
| naming hoping that people won't find out :-) That company has
| become such a failure. What happened 5 years ago?
| topspin wrote:
| This first appeared six months ago.
| gerdesj wrote:
| https://google.github.io/security-research/pocs/linux/bleedi...
| baybal2 wrote:
| WiFi stack, and drivers would be even more scary to look at.
| atat7024 wrote:
| Or kernel, where there are known unresolved issues -- no
| looking required.
| dopu wrote:
| This might be a pretty naive question, but: in a hypothetical
| world where the vast majority of systems programming is done in
| "memory safe" langs, what would most vulnerabilities look like?
| How much safer would networked systems be, in broad strokes?
| hezag wrote:
| A related post from Google Security Blog[0]:
|
| > _" A recent study[1] found that "~70% of the vulnerabilities
| addressed through a security update each year continue to be
| memory safety issues." Another analysis on security issues in
| the ubiquitous `curl` command line tool showed that 53 out of
| 95 bugs would have been completely prevented by using a memory-
| safe language. [...]"_
|
| [0]: https://security.googleblog.com/2021/02/mitigating-memory-
| sa...
|
| [1]: https://github.com/Microsoft/MSRC-Security-
| Research/blob/mas...
| cyberpunk wrote:
| Likely we'll have less 'os-level' pwns, but to be fair these
| aren't really the most exploited class of vulnerabilities today
| anyway. I'm just as effective doing a sql injection and
| stealing your client's PII if you have or don't have your
| bluetooth stack written in a lang that prevents some memory
| corruption exploits from being feasible, and that's the actual
| goal of most attacks.
|
| You're going to get owned in future by people obtaining creds
| to important stuff (say, aws creds) and by crappy userspace
| applications, we can hope that OS security continues to improve
| but even if it does get bulletproof the story is far from over
| while our apps are all piles of garbage.
|
| At least, that's what I recon'
| kevincox wrote:
| Of course proper escaping/parameterization can be enforced in
| a good quality library as well. So hopefully we will see SQL
| injections in the future as well if these safer libraries
| become the default.
| citrin_ru wrote:
| Web development is done mostly using "memory safe" languages
| and we can see that it is far from being secure. The list looks
| like: https://owasp.org/www-project-top-ten/
|
| Which is not to say that "memory safety" is not a significant
| issue in C/C++. I wonder why wuffs [1] is rarely used in C
| projects to parse untrusted data given that it can be
| translated to C.
|
| [1] https://github.com/google/wuffs
| ipsin wrote:
| The write-up doesn't appear to have any author details, but the
| main page [1] credits Andy Nguyen.
|
| [1] https://google.github.io/security-
| research/pocs/linux/bleedi...
| BenoitEssiambre wrote:
| I should be safe. After the latest ubuntu update, my bluetooth
| refuses to connect.
| dkarras wrote:
| As they say, bluetooth in linux keeps only the honest people
| out.
| zdwolfe wrote:
| At least it's not display drivers anymore
| rvz wrote:
| Would be even more worrying if macOS or iOS also had these sort
| of bugs in the bluetooth stack. Plenty of iOS/Mac users using
| AirPods these days since Apple removed the headphone jack.
| Bluetooth is already turned on in the default install.
|
| Going to put this comment here as a reference to quote later when
| I see a zero click RCE for iOS devices using Bluetooth for drive-
| by exploitation.
| zibzab wrote:
| OSX had I similar issue in WiFi drivers while back (also thanks
| to Intel), so it's not impossible.
| young_unixer wrote:
| Does anyone pay bounties for this kind of vulnerability in the
| kernel or in widely used low-level libraries? I mean legally, not
| in darknet markets.
| Alekhine wrote:
| What kinds of attacks could we actually see with this? Servers
| don't use bluetooth and desktops often don't, but Linux laptops
| and IOT devices often do. With Linux laptops being a rarity and
| IOT devices already being insecure pieces of crap whose value to
| a serious attacker is questionable, I fail to see how relevant
| this is for the average tech user.
| cesarb wrote:
| Many desktops nowadays come with wifi, and wifi cards often
| also have Bluetooth. I just looked at a nearby Dell desktop
| (which came with wifi built-in), and it shows Bluetooth as
| enabled.
| ptsneves wrote:
| Android has a Linux kernel and uses it's stack. As a person in
| the field I can tell you that the IoT is not just smart lights.
| There are starting to appear smart sensors or even car
| infotainments which are Linux inside. Sure, car infotainments
| are not controlling the engine power or throttle but it is for
| sure requesting engine start up or displaying the glass cockpit
| in modern cars. Otherwise how do you think you can turn on the
| car with the new fancy app?
|
| From what I see we are going back from general computers
| running an old version of windows xp or red hat into special
| purpose Linux system on a module devices.
| mondoshawan wrote:
| Android has a Linux kernel, but uses a totally different
| bluetooth stack called Bluedroid, and speaks raw HCI to the
| controller, bypassing all bluetooth drivers in the kernel.
| michaelmrose wrote:
| Infotainment isn't well isolated from the more important
| parts of the car which use the same bus.
|
| For example I recall reading there was an example of a car
| which wouldn't trigger collision avoidance during a phone
| call because it was erroneously triggering the breaks to a
| very small degree and the logic was not to trigger the breaks
| when the user was already braking.
|
| There is every reason to believe security is as mediocre on
| cars as elsewhere.
| outworlder wrote:
| Bluetooth peripherals are relatively common even for desktops.
| ITX boards in particular commonly have bluetooth and wifi
| built-in.
| phendrenad2 wrote:
| Every week there's a new vulnerability in the Linux kernel - is
| it time to admit that (A) the "many eyes" theory is disproven (B)
| the Linux kernel has evil malware agents "oopsing" bugs in
| exactly as fast as we discover them?
| Kaze404 wrote:
| This comment is clearly bait, but I'm going to take it anyway
| and respond with a link to Microsoft's Security Response
| Center. This isn't exclusive to Linux at all (for better or
| worse) https://msrc-blog.microsoft.com/
| phendrenad2 wrote:
| Would be nice if we could judge Linux on it's own merits,
| without comparing it to Microsoft Windows. "Your Ferrari only
| goes 30mph? Well it's still better than this lawnmower. Stop
| complaining."
| pessimizer wrote:
| If Linux is a Ferrari and the dominant commercial operating
| system on earth is a lawnmower, there's no metric by which
| Linux is failing other than grass-cutting.
| kzrdude wrote:
| IMO, the quip about "many eyes" never was true, but you know,
| that doesn't invalidate open source or anything, it just means
| that Linus said a thing that sounds cool to a magazine and it
| was just hot air. That saying, was.
| filoleg wrote:
| > the "many eyes" theory is disproven
|
| The way I see it, all those vulnerabilities prove the opposite.
| If there were no "many eyes", I doubt most of those
| vulnerabilities would have been exposed to the public at all.
| But I bet that malicious actors would still be using those.
|
| That argument you made reads similar to "hospital theory is
| disproven, because whenever we get more hospitals and doctors,
| more people end up with a diagnosis".
| Godel_unicode wrote:
| The "many eyes" theory includes the phrase "all bugs are
| shallow", which to me certainly implies that they shouldn't
| lay there for 10+ years.
|
| The only conclusion people should be drawing from the last 20
| years of security being taken seriously is that writing
| secure software is hard, finding bugs is hard, and business
| model doesn't really matter.
| WesolyKubeczek wrote:
| The maxim doesn't state an exact eyeballs-to-bugs ratio,
| nor does it state a timeframe in which the bugs actually
| become shallow.
|
| It's quite possible that for 10 years, the number of
| eyeballs had not been enough, until it was. The open source
| model makes it more likely to gather more code reviews.
|
| I hope you and the grandparent get your horses into rehab
| once you finish your ride. ;-)
| lanstin wrote:
| The bug was found by fuzzing, so not really the case that
| anyone reads the code. I'm pretty sure code reviewers are
| a lot slacker now than in 1995. There's just so much
| code, and so often the costly things are in bad thinking
| that leads to unmaintainable messes not bad security.
| baybal2 wrote:
| What to say, very solid work
| [deleted]
| phab wrote:
| Clearly I'm missing something - in BadKarma, why does the
| compiler not baulk at sk_filter being passed a struct amp_mgr*
| instead of a struct sock* as expected? A type confusion like that
| ought to be prevented during typecheck, no?
| loeg wrote:
| It's indirected via `chan->data`, which is probably a `void*`.
| (Implicit) pointer casts between `void*` and other arbitrary
| types are allowed.
___________________________________________________________________
(page generated 2021-04-07 23:00 UTC)