Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Android Security Communications Network Networking Privacy Wireless Networking

Android Devices Can Be Fatally Hacked By Malicious Wi-Fi Networks (arstechnica.com) 154

An anonymous reader quotes a report from Ars Technica: A broad array of Android phones is vulnerable to attacks that use booby-trapped Wi-Fi signals to achieve full device takeover, a researcher has demonstrated. The vulnerability resides in a widely used Wi-Fi chipset manufactured by Broadcom and used in both iOS and Android devices. Apple patched the vulnerability with Monday's release of iOS 10.3.1. "An attacker within range may be able to execute arbitrary code on the Wi-Fi chip," Apple's accompanying advisory warned. In a highly detailed blog post published Tuesday, the Google Project Zero researcher who discovered the flaw said it allowed the execution of malicious code on a fully updated 6P "by Wi-Fi proximity alone, requiring no user interaction." Google is in the process of releasing an update in its April security bulletin. The fix is available only to a select number of device models, and even then it can take two weeks or more to be available as an over-the-air update to those who are eligible. Company representatives didn't respond to an e-mail seeking comment for this post. The proof-of-concept exploit developed by Project Zero researcher Gal Beniamini uses Wi-Fi frames that contain irregular values. The values, in turn, cause the firmware running on Broadcom's wireless system-on-chip to overflow its stack. By using the frames to target timers responsible for carrying out regularly occurring events such as performing scans for adjacent networks, Beniamini managed to overwrite specific regions of device memory with arbitrary shellcode. Beniamini's code does nothing more than write a benign value to a specific memory address. Attackers could obviously exploit the same series of flaws to surreptitiously execute malicious code on vulnerable devices within range of a rogue access point.
This discussion has been archived. No new comments can be posted.

Android Devices Can Be Fatally Hacked By Malicious Wi-Fi Networks

Comments Filter:
  • Now all you have to do is connect to wifi and these pricks can screw you. Thanks, Broadcom!

    • by Anonymous Coward

      Now all you have to do is connect to wifi and these pricks can screw you. Thanks, Broadcom!

      It's actually worse than that -- as long as you're in range of the malicious Wi-Fi network, you can be hacked. So, only way to avoid this? Turn off Wi-Fi completely unless you know you're patched.

      • Re:Wonderful (Score:5, Insightful)

        by piojo ( 995934 ) on Thursday April 06, 2017 @12:57AM (#54183663)

        So, only way to avoid this? Turn off Wi-Fi completely unless you know you're patched.

        Don't forget to turn off wifi+location services integration. Recent versions of Android push you to scan for wifi networks for location services, even when wifi is disabled. So you'll lose location accuracy, in addition to losing wifi.

        • Re:Wonderful (Score:5, Informative)

          by monkeyzoo ( 3985097 ) on Thursday April 06, 2017 @05:22AM (#54184129)

          It's not actually as bad as all that luckily. From the blog post, the attack can only be performed by another peer on the same wifi network. So at least if you are on a secure, private network, you are safe.

          Lastly, as we’ll see later on, triggering these two vulnerabilities can be done by any peer on the Wi-Fi network, without requiring any action on the part of the device being attacked (and with no indication that such an attack is taking place).

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      And this is why companies such as Broadcom, Cisco, Qualcomm, Intel, Marvel, (name your favorite chip vendors here) ... who wish to make gazillions on supplying what is increasingly *critical infrastructure*, not just 'fun stuff', need to be compelled via legislation and trade treaties to make their firmware stacks available for audits on a continuing basis by security professionals and subject to binding actions based upon those audits to fix issues as they are found. Fine, they don't have to open-source it

      • Re:Wonderful (Score:5, Interesting)

        by Anonymous Brave Guy ( 457657 ) on Thursday April 06, 2017 @12:32AM (#54183581)

        This sort of argument gets made every time there is a breach in any proprietary system, but where exactly are you going to find these "security professionals" to carry out detailed audits on entire firmware systems every time someone released a new product? Who's going to pay their bill? What good is a fix from a SoC manufacturer if the suppliers of devices incorporating those SoCs or the networks reselling them don't then supply an OTA update in a timely and secure fashion?

        The idea that enough eyes make all bugs shallow might be one of the most dangerous fallacies in computing today, but even if it were true, it would still only be the first step to fixing a problem like this.

        • but where exactly are you going to find these "security professionals" to carry out detailed audits on entire firmware systems every time someone released a new product?

          I'm not the OP you're responding to but I would assume the idea was that the chipset manufacturers have to pay for it.

          It would make sense for a law to say something like - unless your customers can[1] do the work themselves (i.e. have access to the source code, chipset documentation and build tools) then the company is responsible for doing

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            I'm not the OP you're responding to but I would assume the idea was that the chipset manufacturers have to pay for it.

            Ah yes, the old argument that manufacturers should pay more from their magical money trees.

            The only person that pays for anything is the end consumer, and they've long since proven that they are not willing to pay for any level of security. The only thing that will get them to pay more than the cheapest price is shininess and peer pressure (which is related to the in-vogue definition of shininess).

            • The only person that pays for anything is the end consumer

              In that case let's relieve them of their copyrights and patents on the device so that somebody can fix it without being sued.

            • The only thing that will get them to pay more than the cheapest price is shininess and peer pressure (which is related to the in-vogue definition of shininess).

              I don't know about your country, but in civilised countries we make sure you don't die from eating unhygienic sausages, for example, by making it illegal to sell them, so even consumers that just go for the lowest price are at least somewhat protected. Does this raise prices? Perhaps a bit, but considering the alternative I think this is irrelevant.

              Requiring some regulations for the `hygiene' of network hardware makes sense to me, at least as something that is worth considering.

              • The trouble is, we don't know how to make bug-free, perfectly secure software and hardware yet. Requiring the SoC manufacturers to meet a practically impossible standard isn't going to put prices up "a bit", it's going to increase them dramatically, and it's still not going to solve the problem, it's just going to make the luckier insurance companies underwriting those manufacturers a bit richer.

                If the idea of better regulation is going to go anywhere useful, it has to push manufacturers and those along the

                • I don't know about your country, but in civilised countries we make sure you don't die from eating unhygienic sausages, for example, by making it illegal to sell them, so even consumers that just go for the lowest price are at least somewhat protected.

                  If the idea of better regulation is going to go anywhere useful, it has to push manufacturers and those along the supply chain towards an achievable better position, and it has to do so with a cost that is commercially viable. I'm not sure that's what some of the people posting in this discussion are asking for.

                  The standard for food is not that you never ship tainted product. The GP overstated the case when they said they "make sure you don't die from eating unhygienic sausages". The standard for food is that you comply with all applicable safety regulations, and comply with any mandatory recall of any of your products which turn out to be tainted. Ideally you develop a sense about when a recall will be mandatory, and issue one voluntarily before that actually happens. But nobody expects that food will never be ta

                  • Again, it seems we basically agree on this one in principle, but again, I'm perhaps a little wary in practice. When we start talking about regulating software development, and so recognising accepted good practice in some way, that implies that there is someone qualified to judge what good practices actually are and some reasonable basis for determining what the regulations should be. My personal view is that I'm optimistic about the future but we're not there yet.

                    In particular, suppose we tried to move in

        • The idea that OSS will get reviewed in a way that "all" bugs are caught is a ridiculous one, and if you see people espouse it, you are correct to mock them. But the idea that code reviews will happen simply because code is owned by a proprietary commercial vendor who has the money to do them would also be ridiculous.

          The idea as I understand it is that OSS means that there is the potential for people to catch these bugs while reviewing the code for one reason or another. And if a hole (or bug) is discovered,

          • Yes, I agree with pretty much everything you're saying. I also think it's important to distinguish a theoretical benefit, where it's possible to conduct such a review and possibly to fix problems yourself, from a practical benefit, where someone actually has the time and skills to do that or the time and money to get someone else to do it.

      • by ls671 ( 1122017 )

        to make their firmware stacks available for audits on a continuing basis by security professionals and subject to binding actions based upon those audits to fix issues as they are found.

        Well, if this works as well as OpenSSL, at least we could say it is a starting point I guess...

    • Now all you have to do is connect to wifi and these pricks can screw you. Thanks, Broadcom!

      Slashdotters don't care as long as their hacked phone has a headphone jack.

    • by gweihir ( 88907 )

      Ah, Broadcom. The fuckups of the chip-world. The same morons that deliver the truly bad chip on the Raspberry Pi, with bad USB, no sound, no Ethernet and nobody knows whether the I/O is 5V tolerant or not.

  • by Anonymous Coward on Wednesday April 05, 2017 @10:50PM (#54183381)

    Is it time we ask ourselves if the industry would be in a better place if Windows had won in mobile?

    • Re: Windows mobile (Score:3, Informative)

      by Anonymous Coward

      The flaw is in the Wi-Fi controller, not the OS. That's why this hit both iOS and Android.

      • by Anonymous Coward

        In a well-designed system, a flaw in the Wi-Fi controller should not have such critical consequences. Therefore, Tanenbaum was right and Torvalds was wrong. Hopefully, when HURD makes a release, everything will get sorted out.

      • No, the OS is at fault. It should be able to protect itself.

    • Considering this is a broadcom problem, I don't see what difference it makes in this regard.

      However in overall security, I somewhat doubt it:

      http://www.computerworld.com/a... [computerworld.com]

      Keep in mind, Windows had a super tiny mobile market share even at the time, and still manages to be responsible for 80% of malware on mobile networks. And yes, windows phone isn't immune, nor are Microsoft's lofty promises about how awesomely secure Edge is:

      http://www.tomshardware.com/ne... [tomshardware.com]

      • Considering this is a broadcom problem, I don't see what difference it makes in this regard.

        However in overall security, I somewhat doubt it:

        http://www.computerworld.com/a... [computerworld.com]

        Keep in mind, Windows had a super tiny mobile market share even at the time, and still manages to be responsible for 80% of malware on mobile networks.

        Bogus clickbait article that is plain wrong. Its counting *Windows PC's* that are connected via mobile data as mobile phones, given the dominance of them in the desktop market and that most virus are targeted at desktop of course they dominate stats.

        Given the tiny % of Windows Mobile phones it is obviously quite ridiculous to claim they account for 80% of malware. I'm not aware of any real windows mobile malware.

        The vast majority of mobile malware is Android, because of its market dominance, pathetic securi

        • Bogus clickbait article that is plain wrong. Its counting *Windows PC's* that are connected via mobile data as mobile phones, given the dominance of them in the desktop market and that most virus are targeted at desktop of course they dominate stats.

          No shit, dumbass. Read what I wrote: "80% of malware on mobile networks"

          Given the tiny % of Windows Mobile phones it is obviously quite ridiculous to claim they account for 80% of malware. I'm not aware of any real windows mobile malware.

          The vast majority of mobile malware is Android, because of its market dominance, pathetic security model and total lack of security updates.

          Honestly, you're buying propaganda from the antivirus industry, which is panicking right now because the desktop market is shrinking along with its consume revenue, and nobody is buying their crap where all of the consumer money is going: Android. So what do they do? Sell you a non-existent problem.

          The fact is, 80% of malware on mobile networks is from Windows, of any variety. Let that sink in: Few Windows devices are on Mobile networks

    • by gweihir ( 88907 )

      Well, there are levels in Hell. Android with Broadcom hardware is somewhere in the middle, is my guess, i.e. "truly bad". For Windows Mobile, they would probably have to add a sub-basement to Hell though.

  • by Anonymous Coward

    neither of you read this, did you?

    "... by Wi-Fi proximity alone, requiring no user interaction."

  • Blog post (Score:5, Interesting)

    by 93 Escort Wagon ( 326346 ) on Wednesday April 05, 2017 @10:54PM (#54183399)

    That was one well-written blog post! Informative, detailed, yet easy to read... and bloody long.

    I got a kick out of the fact that this incredibly long blog post is titled "Part 1".

    • I see from the author's blurb that he has significant professional experience. s/blogger/reporter/

      It's too bad Broadcomm doesn't seem to. On a 90-day disclosure it looks like they acknowledged the bug with two weeks left to go, asked for an extension, and now it'll be four months before typical users get patches for an exploit that is going to be stealing banking passwords in train stations next Monday (or more interesting data on the BART or DC Metro).

      Apple is making a strong case for using its products

    • Love the post/sig irony!
  • by Anonymous Coward

    that the carriers (who sell the majority of the affected phones) are totally on top of the latest security fixes and always push them out to their customers right away.

  • by Anonymous Coward

    Thanks, Broadcomm, and other binary-blob firmware peddlers, for royally fucking up and not giving a damn.

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Thursday April 06, 2017 @12:26AM (#54183565) Homepage Journal

    Many driver manufacturers insist on providing BLOBs (binary loadable object files) for drivers to load into their devices, or they have the firmware stored in their devices. What we can't see probably has security errors that we can't fix, but as this shows, the bad guys can find them.

    Your system already has backdoors like this. In drivers that load BLOBs and devices that run proprietary firmware, and in the Intel Management Engine.

    • by piojo ( 995934 )

      If they don't use BLOBs, wouldn't that just mean the vulnerabilities are baked into silicon? I thought BLOBs were just a way of abstracting logic from hardware to software. Is the problem that a BLOB is actually being overwritten in a way that isn't possible for logic baked into hardware?

      • by Bruce Perens ( 3872 ) <bruce@perens.com> on Thursday April 06, 2017 @01:56AM (#54183801) Homepage Journal

        If they don't use BLOBs, wouldn't that just mean the vulnerabilities are baked into silicon?

        Your device generally includes some sort of CPU, which is usually programmed in C. It might also include a gate-array program, which is written in verilog or VHDL. Backdoors and bugs live in both of these things.

    • While it's great that you pointed out the problem, I wish that you would also mention the projects that are working on solutions, such as Replicant [replicant.us] and Libreboot [libreboot.org]. The world needs more people working on stuff like that, and you could lend those sorts of projects some of your fame and credibility.

  • by cyber-vandal ( 148830 ) on Thursday April 06, 2017 @12:52AM (#54183647) Homepage

    We've got your money now fuck off.

  • We must have it or we're fucked. I've been telling this [altervista.org] to Google for years, but they don't seem to be interested. As a result we have literally hundreds of millions of Android devices with dozens of remote vulnerabilities, the devices which aren't supported and cannot be upgraded to anything else. And it's getting worse day by day.
  • Wireless Worm (Score:5, Insightful)

    by mentil ( 1748130 ) on Thursday April 06, 2017 @02:20AM (#54183859)

    I recall years ago, reading about a study which found that unpatched Win XP systems would get pwned in an average of ~5 seconds, once connected to the internet. This was due to old, long-since-patched worms like Blaster and Sasser, that still lived on in unpatchable systems. I imagine in the near future there will be a worm where every pwned device activates its wifi (even if the official wifi setting is set to 'off') and attacks every nearby device. EOL phones will be permanently vulnerable (how many iphones use this Broadcom chip yet are ineligible for iOS 10.3.1?), just like those permanently unpatched WinXP systems. It's an even worse situation on Android devices that are supported for a few months on average.

    Ironically people will have to enable wifi in order to download the firmware update to patch this bug, if their OS only allows OS updates via wifi.

    • by AmiMoJo ( 196126 )

      As usual though, the risk is blown way out of proportion. For example, the XP issue was trivial to mitigate - just turn on the built in firewall. A lot of people seem to think that the firewall was introduced with Service Pack 2, but actually all that changes what that it was enabled by default.

      This vulnerability affects the processor inside the wifi chip. The proof of concept writes data into its memory. This is a separate subsystem to the main phone CPU, with its own RAM and address space. So to use it to

      • by mentil ( 1748130 )

        A wifi driver exploit wouldn't be necessary. The wifi chip hack could send/modify packets of data to the device which leads to a malware infection via a different vector. Say, a HTML redirect to a website that contains a jailbreak malware hack. Or whatever other iOS exploit. It can go right through the wifi driver, if packets are expected to be received (and who wants to bet a daemon is always listening). May not work for SSL connections, but it can just wait patiently for an unencrypted connection.

    • I recall years ago, reading about a study which found that unpatched Win XP systems would get pwned in an average of ~5 seconds, once connected to the internet.

      Yeah, don't do that. A firewall solves that problem, unless you've got owned devices on your network. Even then, give it its own VLAN etc.

  • by Xanni ( 29201 ) on Thursday April 06, 2017 @04:52AM (#54184093) Homepage

    The attack doesn't require a rogue access point, as it uses a Peer-to-Peer (Ad-Hoc) WiFi protocol. Vulnerable WiFi chipsets can be attacked by any other WiFi device in range.

    • by monkeyzoo ( 3985097 ) on Thursday April 06, 2017 @05:20AM (#54184125)

      Not exactly. From the blog post, you can see that the attack can only be performed by another peer on the same wifi network. So at least if you are on a secure, private network, you are safe.

      Lastly, as we’ll see later on, triggering these two vulnerabilities can be done by any peer on the Wi-Fi network, without requiring any action on the part of the device being attacked (and with no indication that such an attack is taking place).

  • by Anonymous Coward

    I wonder if all these fancy new Raspberry Pi's with closed source Broadcom chips are affected?

  • by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Thursday April 06, 2017 @09:22AM (#54185037) Homepage Journal

    CM died and begat Lineage OS. And now I'm getting ~weekly updates for my Moto G 2nd, which has of course been left behind by Motorola.

    OSS FTW

    • Does Lineage OS still give you the Moto X gesture features?
      Like shake for flashlight, twist for camera, turn on screen when hand approaches?

      It was my understanding these are controlled by a secondary processor and the Moto app.

  • Comment removed based on user account deletion
  • Are you going to release this security patch? My 2nd gen Moto X is still on the August patch level.

  • What other devices are going to be vulnerable to this - there's a hell of a lot of things using Broadcom wifi chipsets.. pretty much everything from Ambarella (so that's GoPros and most of the GoPro alternatives), plus Wifi routers, IoT devices, baby monitors....

Time is the most valuable thing a man can spend. -- Theophrastus

Working...