Broadpwn: Remotely Compromising Android and iOS via a Bug in Broadcom's Wi-Fi Chipsets

so we're going to be talking about how to remotely exploit ios and android devices via bug that we have named broadband there's been quite a lot of buzz about broadband recently so we want to tell you why we think it's a very special interesting and powerful bug and also tell you a bit about the process that led us to this barber but first of all let me just introduce myself my name is Nita Orenstein I've been doing reverse engineering and vulnerability research for about as long as I remember I'm mostly interested in Android and some low level systems such as baseband Wi-Fi chips boot loaders and I've been doing that for approximately the last five years so we're going to be talking about broad bonus our remote exploit the for the first remote exploit in quite some time to be public and first of all we're going to be defining what a remote exploit actually is so in our opinion a remote exploit is not a browser exploit and we're going to be explaining exactly why and we're going to be discussing how we found this particular exploit in in a specific and interesting attack surface that was almost unexplored until now and we'll be concluding with how we leverage this bug that we found into the first fully functional remote exploit to be public and in recent years so first of all what a remote exploit isn't we've all been hearing the news about various government agencies in some countries attacking dissidents and other people with browser bugs sending the message messes with malicious links now we believe that if you need the victim to click a link and to actually interact with with any particular link or whatever you sending him then that's not a remote a remote is something totally different it does not require social engineering so let's define what the remote actually is so these are the three laws three laws of remote exploits I suggest you take a picture because there's going to be a quiz later on sorry yeah so memorize these three this wee laws first of all a remote may not require any human interaction to trigger that means you can't click on an SMS a link you can't open an email that's not a remote that's actually we consider it to be a local exploit then a remote may not make assumptions about the system that it's attacking and there's a very simple reason for that when you attack a target remotely your attack surface is much more limited you have a much more limited interaction with the target so supposing you're attacking a kernel or a browser you normally have some kind of interface to get feedback to get some kind of data about the state of the system it helps you with assumptions you need to make about the exploit you can't make these kinds of assumptions in a remote and the third important rule is a remote must leave the system in a stable state that's because you want to be persistent you want to keep a stable presence and you don't want to alert the target that you're attacking so this class of bugs have been very very prominent early two-thousands we all remember various worms and malware in Windows during those years you really didn't need to do much other than connect to the internet and your computer was already owned and you didn't know anything about that happening and these days are long gone so why well there's been a lot of mitigations and awareness about remotes and if we look at the Three Laws they're difficult to keep up because to find remotely exploitable bug that doesn't require any interaction from the user is almost impossible because the attack surface is much more limited when you're attacking a target remotely it's also difficult because you need to make assumptions about the system because you have a SLR SLR randomizes the address space so you never actually know for certain where any addresses are you need some kind of a leak to know that and that's a problem because you have a limited interaction with a remote target and another issue is that you cannot make any mistakes against remote targets because normally if suppose you're attacking a kernel if you crash it there's a panic and you're done so so you're in a difficult position where you cannot make any assumptions and yet you cannot crush the system so obviously this is a very difficult goal and late last year Google project zero have announced a special bounty for remote exploits for Android whose $350,000 if I remember correctly there was not a single submission so apparently either this is too low for that kind of for that kind of exploit or it really is as hard as we think so in attempting to resolve this problem about how can we get a remote exploit against fully hardened mobile phones such as Android and iOS we started looking at the system from a higher level so we have the main application processor both in Android and iOS and as a lot mitigations going on they're out of hardening first we have d'Epinay SLR which prevent which both prevent code running from arbitrary places in memory and prevent us from making assumptions about the memory space and there's various new medications such as span in pxn which prevent us from jumping to user and from the kernel or accessing data that we're not supposed to from userland or from the kernel so that's really hard work for us to develop an expert in such conditions especially a remote one so we've started looking around the neighborhood looking at a mobile phone but not at the main application processor and we've come up with kind of two alternatives to other chips that exist both on iOS and Android that have a very very extensive interaction with the application processor so one of them is the baseband which handles 3G and 4G communication along with many other tasks and another is the Wi-Fi chip both of them have connection via various interfaces such as PCIe to the application processor so they're in a much more convenient position to attack the kernel the main system so we started having a look at those two subsystems and first of all we've considered based bands briefly now basements are a fascinating attack surface very interesting very fruitful ground for bugs but there's a problem of fragmentation especially recently up until a few years ago Qualcomm or the market leader they were dominate dominate in this field but recently there's been quite a few new competitors grabbing popular devices have moved to to enter into Intel chips Samsung have moved to the Shanon based bands though the Nexus of still with Qualcomm but other lower end LG and HTC have moved to mediatek so really if you develop any sort of exploit or find a bug in a base band that would not get you very far in terms of the percentage of devices you would be able to attack so we've looked at the Wi-Fi chip and there the picture was very different Broadcom are a clear market leader there have been in all the iPhones since the iPhone 5 almost all Samsung galaxys and notes all of them that we've checked that's the s3 all the way through s8 and all the notes most Google Nexus S since Google Nexus 5 and there's been some various ages and HTC's that use them although not universally so obviously this is a much more interesting attack surface because you don't have to repeat your work if you find one bug you can use it in plenty of places so and there's a bonus here we've discussed how a seller makes remote exploits almost experiments are impossible without some kind of an info leak or an ability to to brute force the address space to find addresses and in this case that's not a problem because on the Wi-Fi chip or memory is read/write/execute there is no depth and nor SLR it's basically a 90s party so let's start diving into the Wi-Fi system and chip and see what makes it interesting so first of all there's been a lot of work about this particular system in the past and we've learned a lot from what other security researchers have done so the most recent work is gardenia meaning of project zero always done some amazing research about this particular Broadcom chipset his office also found some few very nice but then there was the next month project by the semo group if I'm pronouncing correctly and they've developed a very nice tool set for hooking and debugging Broadcom chipsets and that's also been extremely helpful for us to debug and to develop the exploit there was a bunch of Israeli researchers in recon so we're kind of the pioneers in this field they've believed the first tranche together with Andres Blanco to actually work on patching the quality the basement Broadcom chipset and making it do various things that it's not supposed to so I'd like to say thank you to all these researchers and this is an example of how we all help each other with this with the research we do so another helpful thing about about those Broadcom chips is that broad comms Wi-Fi division was recently purchased by Cyprus who open sourced a lot of the specs this is uh this is the diagram for the Broadcom four three five four which powers the iPhone 6 and I've simplified it for you so our basic architecture of a bit of Broadcom chip is so we have an X I backplane which connects the various parts then we have the main the main microcontroller which is an ARM Cortex of four then we have d11 fight ship which handles which handles RF and actually processing packets from over-the-air then we have PCIe or SDIO which connect this whole system to the main to the main ship to the main processor via PCIe works by a DMA stas the arrow is a proprietary Broadcom interface which is I believe slowly being phased out and then we have about 900 care from in ROM or neuro chips ROM actually holds most of the instructions most of the code rom was most of the code rom is mainly for patches for for bug fixes so basically every once in a while there's a jump to a function table and there it is and that's where they brought the function table is in ROM and that's where the rod come people can put any jumps to newark code that they want to do patch so to reverse this firmware was pretty extensive project it uses a proprietary real-time operating system known as a gen DRTV it was kind of a pain to reverse it the code is pretty complicated and there's a lot of functionality which you need to reverse from scratch but fortunately the source is leaked at a very at about five years ago and digging through Google with various function names led us to these proprietary Broadcom sources which were included with a project known as vm g once we want to apparently the Broadcom drivers were compiled rather than supply this in binary form which means that a lot of the source code is available so this really helped us gain some perspective into the system so after getting a perspective about the basic functionality of the system and what it does we wanted to dig in and look at the right attack surface to actually find a place that could give us a remote bug a remote a remotely exploitable bug because this was the purpose of the whole project so now's the time for a first quiz who remembers the first law of remotes you can just shut it out yeah you can't interact with humans so what we needed in in security terms is an exploit a bug that doesn't require authentication in order to trigger which means that the user actually doesn't need to actively connect or log in to any specific place or connect to an access point so that's a rather tall order and let's see how we approached it so here's some basics about the Wi-Fi Association process before you actually reach wpa2 and any of these encryption matters which are supposed to to protect you traffic there's a very simple packet exchange between the station between the client and the access point and that's the association process it begins with our probe request on behalf of the station the client the client basically is looking for access points to connect to if an access point is nearby and it's configured to allow anybody to if it's configured to advertise its presence then it sends out a probe response then there's an exchange of the an obsolete set of packets known as open sequence which is to be there to implement WEP which is now obsolete and then if the client actually wants to connect to this access point it issues an association Association request then the access point if it wants read the can't connect issues a response and then they start to exchange data now the authentication process is only inside this last phase within data wpa2 is implemented on top of this association process it's not a part of it which means that there is no authentication in all of these phases in phases that we've described now I know you're asking a question there's a catch here right anybody wants to like shout out what's the catch because probably somebody must be thinking about it sorry yeah okay one issue here is that you must be thinking the client actually needs to choose to connect to an access point to in to initiate this process of association and that's basically true except for a mechanism built into probe probe requests in Wi-Fi which is that a client actually advertises the SSID is the access point names that it's looking for so for instance if you are Bob and you've connected to an access point called Bob home every once in a while you send out probe requests if you're not associated with this name of that particular access point so so let's let's see an example from their real world I was sitting in one of the halls just now with arrow dump look at unassociated glands looking for for their home access points let's have a look at what I saw yeah so the hole was actually almost empty but look at all these names I'm seeing look at all these on Associated clients sending out names of SS IDs of access points that they're looking for by the way there's quite a few interesting names here if you look carefully you'll see an access point and you think it was just here a query for an access point called Stuxnet and every once in a while it's pretty interesting to just open air a dump and look at what people around you are looking for it might tell you a lot more about them than you think so so this thing actually lets you treat the association process as if it doesn't require any interaction so long as as a victim has connected to an access point in the past and if you stay around them for let's say a minute or two you should be seeing one of these and the beauty of this thing is that there's no authentication involved in this process so even if it's a wpa2 or a radius access point with the maximum possible provisions for authentication and security you still don't reach that phase so long as you find a bug in this particular protocol because any authentication is done only after this initial exchange of packets so we've convinced ourselves so this is an interesting attack surface sorry yeah so this is an interesting attack surface and now we'd like to begin to examine [Music] how to actually attack it what do we look for so basic Wi-Fi 8:02 basic header it's pretty small it only includes addresses and some bits denoting the frame type and other info there's not much potential for bugs there but the real info the real meat carried in the packet and we're talking about packets for the association process the real meat comes in a variable length addition to the packet it's known as an information element it's appended to the end of the packet and you can have as many information you want in a packet that's the way that access points and clients exchange information between them and the way that they're are constructed is that it's basically just a simple TLV one byte for type one byte for length and then a variable length data area and you can have five ten even more of these II's in a packet depending on the capabilities of the access point and the client what they want to tell each other so this is an interesting place to look for bugs because in old and insecure software it's a known minefield that sometimes programmers don't particularly look at the length field they don't they don't remember to check whether the I look at the buffers they've allocated are big enough to hold the info that they're copying from the packet so naturally that was an interesting place to look for bugs so we wanted to to narrow down our reverse engineering process to those specific places where we think that such bubs could be found to places that actually handle that parsing of those particular information elements so that that was made easy by the art byte by the design of the femur of the code it's very modular you can see that it's divided into particular modules which are being loaded attached when when the chip boots up so that made it very easy to start having a look and pinpoint particular protocols that were interested in and we found this function which helped us a lot this is a function which it's called I am at powers function and this handles this basically registers a callback to handle i'ii teii ease of specific type and you can see there's a field I am type which denotes the ie that the function is supposed to handle the callback and then there is the subtype field which tells you which kind of a packet it is which which means whether it's an association response a request or probe request which packet is it in the association process so it was very convenient to narrow down the protocols which we thought would be particularly complicated or difficult to handle correctly the data being transferred in the packets of the Association process and we've mapped xrefs for four particular modules handling protocols which seemed interesting now this was also a tricky part because for instance you can see some references here to c c xt d LS which are protocols which which are not handled before authentication so that was not really relevant for us we are looking for that small specific subset of protocols which are handled during your association process and that's how we reached our barb eventually so there's a protocol in in Wi-Fi known as the wireless media extensions we don't need to really go into too much depth about what this protocol does it's designed to let the access point know about our quality of service requirements for instance if the client is our handling video or a voice over IP then the access point can give priority to the packets which are handle which handle traffic which requires good performance so there's a field which in which the client specifies what are the what are its requirements whether it supports WME or not and this is being parsed as part of the association process and we've come across this function if you look at it for a second it basically shouts out Bob and again this happens a lot when you deal with embedded systems you find bugs just like they used to look in the good old days so when I was starting out you basically just had to grab 4mm copy in a source code and that's how you found most of your bugs in this case we couldn't couldn't use this technique because we were looking for bugs in a very specific attack surface but once we narrowed down the attack surface to two to a place which can be code which can be reached without any prior authentication that's when we found this bar this this bar but before we actually could confirm that it's a bug we wanted to check that the buffer being copied into was actually too small to hold the data if we look at the bug you can see that there's a mem copy here and we don't see any size check at all anywhere and that means that we can specify an iln as big as we want and when we look at the function which allocates this buffer we see that it's size is only 44 bytes while we have one bytes to in the in the length field which means we can make a maximum of a maximum length of 255 so 255 minus 44 gives us 211 bytes of overflow which is actually very nice because it gives us a lot a lot of leeway often other flows are small they can be 8 bytes 4 bytes and then they're much harder to exploit this actually gave us a lot more flexibility and we started triggering this bug on various devices so this is how it looked on my samsung this is an s7 now this is pretty interesting look at what happens when I trigger the bug so we see that the Wi-Fi system turns off there is some indication to the user but you should probably keep in mind that given that probe request is being sent out without the users interaction it's enough for the phone to be in your pocket and not touch then still it with some aerobic quest and it will associate with an access point if it's if it already recognizes it and just the way you know like you walk you walk home and you take the phone out from your pocket and it's already connected and that's because of this this provision that's because it looks for access points without any interaction from you so in case you do trigger a crash when the phone is doing that when it's automatically looking for access points you will not see any user we will not see any indication to the user at all and after about 5 seconds if you press the chip it comes back up so rather than a disruption of a few seconds for Wi-Fi connectivity there's no indication the story was different on my Mac which was also vulnerable it also had a broad term chip let's look at what happens so I'm connecting to to an access point which sends out the exploit and boom kernel panic so this is a good time to mention that there's a difference in implementation between mobile devices and laptops so in mobile devices Wi-Fi chip sets are used in a setting known as half-full Mac which means that they handle a lot of the work and an association and processing it's basically in layer three stuff it's known as MLM II and in laptops in desktops and laptops it's the kernel which handles it so what we're seeing here is that the Association process is being handled by the kernel and it's choking on our bug in crashing now this is not that good for exploitation and we can talk about it later in the meantime we stay with mobile phones because that was our focus for this research so now let's continue it's time for another quiz who remembers the second law of remotes [Music] no assumptions you cannot make any assumptions about the system and again the reason is that when you're attacking a remote target you have very little indication of the state it's currently in you don't know about its heap you don't know about which files are open you have a much smaller interface than you do for instance when you're attacking a browser and you have JavaScript or you're attacking the kernel and you have Cisco's remotes are completely different you normally have very limited protocols such as the association process which is what we have in this case and that's the only thing you have you cannot make any assumptions so many remote bugs met an untimely death because they couldn't meet this rule because they had to make assumptions who can tell me one word the main killer of remote bugs that requires you to make assumptions start with name ASLR right so with a said are you have to make assumptions about the system and in this case we don't have a cell R so that's already one advantage so let's see if this bug lets us meet the second law so we don't want something very simple we want to avoid a situation where our overflows are overflow puts us on inside dynamic memory memory that means we are in the heap and the locations are changing around us and we have no clear indication of what what we are referring into because it could change from one one from one execution to the other what we do want is to be able to flow into our consistent address and others we can predict we want to be able to predict what's in that address we want it to be as static as consistent with memory as possible we wanted to just sit down and behave nicely not move it must not move so and the third the third thing we want is that data that we're overflowing into needs to be doing something interesting it needs to have pointers which then are triggered in an interesting way so let's see if this bug actually meets what we need so the overflow is into a structure known as PS it's a structure for a structure for handling power saving mode our structure is tight is noise described as current W a memory and the sources that's the name and both of them are static in terms of fabric space they are allocated on startup on boot and given the deterministic allocations that the agent agent DRTV allocator makes we can predict we can consistently predict their locations on on a given system on a given firmware and it it stays consistent across reboots even if you put the phone a hundred times of the addresses remain the same and once we confirm that there was a good lucky point we wanted to check maybe with we want to check if our lock remains consistent so we had to look at the PS struct and we looked for interesting pointers data which is handle in an interesting way which helps us in an exploit and what we found are all these timers and timers are very good news when you're preparing an exploit because timers are called regularly they do something every once in a while and they not only trigger other call other code for instances callbacks so of course that that immediately seemed interesting and we started digging around at what these timers do and when they're called and we reach this function as you can see throughout this process we were extremely lucky first in finding a bug in an association in the association process which doesn't require any authentication then in finding a bug which overflows into static memory and now in this so if you look at this code towards the end you can see a very clear write primitive it takes an address from the overflowed object it takes a specific offset from this address of 14 in hex and it tries to that offset so again this is very simple very clear and we just you know it was our lucky day now we have a right time ative where do we write to so as we briefly mentioned there's a table of functions in RAM which is used as a way to patch functionality and add security security fixes what Broadcom do is whenever there is a fix whenever there is a patch they change this function table to point to the patch and the code in the ROM at specific intervals at specific points in the code jumps to this table and you know there's basically hooks which we direct the code the code can check whether there's a there's any change and then it comes back to the ROM so this was a good place to overwrite because because this table can stay relatively consistent across different ephemeral versions and it's possible to predict what the particular offset will which function will be in a particular offset so we decided to write to that table and then we had another problem in the exploit which is that we only had 24 bytes for shellcode so you can't do much with 24 bytes that's not a place where you can put a a payload which does anything useful and that led us to consider where's a good place we can put our payload now the way you normally solve these problems in expert development is that you look for some kind of a stray primitive a way to write to large areas of the heap with your code so you can predict where this code is we didn't really see this option in in the broad confirmer there's the we didn't find any good location primitives in the limited protocols we had access to as part of the Association process so be given that this is a Wi-Fi chipset that this is a code which handles packet can anybody make a guess about where we could write large large quantities of data pretty freely can you like make a guess so there's a concept known as a ring buffer in network implementations which is a circular buffer which holds packets as they come in and then it overrides the beginning of the buffer as the buffer gets filled up and this is where packets are are copied into after they're handled by the layer 1 chip and this looked like a perfect place for us to put to put our to put our payload now the only thing we needed to do now is to write some egg hunting code again just like in the good days which 24 bytes was just enough for that it runs through the fluid memory looks for a particular header and when it finds it it jumps to it and in this case our header was in the ring buffer now a nice thing about the ring buffer is that it's all RW eeks so you can basically run code from anywhere you want also in the ring buffer so we jump to the ring buffer after finding our code and and this is the layout of the exploit buffer that we've eventually ended up with you can see we were able to use the overflow to to put our fake timer object at the beginning it jumps to a shell code stub then it jumps to the to the egg hunting code and eventually it jumps to the to the ring buffer now do you remember the third law of remotes you must leave the system in a consistent state oh so we had to clean up a bit we had to restore the buffer that we've overflowed and we had to restore the pointers and make sure that we left the system in our consistent state just the way we found it and with broad porn right now there is no indication or any crash after you run the code so you just run your payload you install your hooks when the system stays stable and consistent and this brought us to their really interesting phase so when I was starting work in this field we had we had worms we had this self-propagating propagating malware which could basically run wild over the network could anybody like remember any particular worms which were famous like just toss out some names yeah yeah and Stuxnet - yep so there are quite a few in the good days and they died out together with remote exploits remote exploits became no longer possible so worms pretty much needed them to propagate but broadband is a perfect bug for that kind of thing so we thought this is a pretty good occasion to make the first Wi-Fi warm and the first network home in a few years so what the way this is implemented is after you after you run your payload in the chip you put some hoops yeah you put some hooks in functions which handle packets and you basically we implement the code which triggers the bug but from within the chip so luckily the bug is pretty simple to implement so the limitations are not that big a deal and we were able to to implement some basic infecting code from within the femur you and still kind of were able to work within the space requirements like the space limitations and that's it what the way the way this works now is a phone gets infected it starts looking for probe requests it sends out whenever it sees a name an SSID it sends out a response starts the initiation process and starts infection now the way it works now is we don't do much other than send out send out a probe request from an infected system saying I am owned that's the only indication we give out so what we're going to do is we're going to show a demo of initial infection and then we're going to show how it skips from phone to phone and oops yeah and then we will actually see the packets being sent over the earth so now I'll switch laptops [Music] okay I hope there's nothing embarrassing on my laptop yeah is this good enough okay so I'm going to turn on broadband wait let's see everything is connected yeah my phone's let's start with this one so I've not offered any given any offering to the demo gods and this demo is kind of complicated because well it requires us to spray a large number of packets into the ring buffer and given that there's all these guys here with them their mobile phones it might be a bit tough you might need to do a few retries but we'll give it a shot so first of all we're going to run broad broad pond there's going to be an access point now it's going to be the name is broad pond test you're welcome to connect and try to crush your phone's yeah okay fine what we're going to do now is we're going to run a spray of beacons you're going to see an access point ap 0 to 4 using using something we're using a tool called take ap the only thing is it does is send out as our payload in a spray over the air so it fills up the ring buffer the ring buffer of the first phone right so we're going to run it now ok it's running now by now actually my phone might be infected because it's supposed to send out set out a probe request let's look at the log I hope it's not infected yet yeah we need to parse the lobs because we're using a special tool called the HD util which extracts them from the chip they're not on the kernel they're on the chip okay has it been infected yet not yet okay I'm just like give it a rub to start scanning okay yeah sorry it wasn't now so you can see that it's it's okay yeah can you see payload triggered so what it does here is it it starts the so it's so the payload needs to restore the CPA star because you know an armed CPS R holds the state for interrupts and everything and the code which basically there's a reason we need to restore it otherwise the chip crashes then we restore destruct the power saving struct it's called WL CPM st and then what we're doing is we're just sending probes which say I am on and waiting for probe requests so now let's look at the other phone which might also already be infected so about s probe requests get sent out about once a minute now the infection is a tricky part it might not work it didn't consistently work but I'm hoping I'm gonna get lucky because you notice that on this project we got pretty lucky a lot of the time right so let's hope this lock stays all the way through I'm going to check the log it might be already infected I don't think it's infected now you can see the hooks but if yeah okay so as you can see the infection process is pretty fast it's just an exchange of four packets and it's already sending probes yeah and here the same thing brought pound payload figured and all that stuff now what we're going to do is to have a look at to see if we can see these just to prove that these phones have been owned we're going to snap using arrow dump to see the I am owned packets to see if they're on the air now I'll first try to work with arrow dump just like that although there's no chance we're going to see anything because there's all a few guys here and it's just going to get swamped so we're going to run some code to filter particular MAC addresses which I know are the MAC addresses of these phones but first you know just for entertainment entertainment let's have a look at what's going on here oh so these are these are it's pretty interesting just to see like who's here these are these are access points but if we move to like different channel you'll see that MGM Resorts which is like the open Wi-Fi that they would have put in here is on channel 11 so if we switch to some channel 2 and put like encryption open it's a way to try to trick arrow dump into showing us just clients so let's just look at clients which are here and unassociated just repeat like that entertainment we had before let's look at like the names being sent out here let's look yeah so here is Alisa is anybody named ELISA here somebody's been to Bissell did you see it y5b so here's a laser again this is very interesting right okay somebody from China cool so now I'm just going to run TCP dump from this script looking specifically for probe requests coming out from these two MAC addresses so I'm just running it letting it capture now the hooks I put are in the function which handles are receiving packets so whenever it receives a packet it sends out a public quest so that's what I need to like to play with the phone a bit that it scans so it receives lots of packets to make sure that that we catch the probe requests on the right channel so I'm playing with it a bit yeah I think that should do the trick ok and show probe ok yeah so you see we have two stations sending out requests I am on and that's it basically game over [Applause] [Music] [Applause]

Channel: Black Hat

Views: 139,101

Keywords: BHUSA, Reverse Engineering, Wi-Fi Chipsets, Information Security, Exploit Development, BlackHat, Black Hat, InfoSec, Black Hat USA, Black Hat 2017

Id: TDk2RId8LFo

Length: 53min 16sec (3196 seconds)

Published: Thu Sep 07 2017

Reddit Comments

[u/[deleted]]

if you ain't got time for the full hour-long talk, I found the slides here.

[u/buttcoins4life]

Just like the ASN.1 vulnerability last year. This can be mitigated by smart security engineering which presumes mistrust of peripherals and modem, basically only being done by the Neo900 project: http://neo900.org/news/about-the-asn1-vulnerability

Also this approach is being done by Qubes OS in the desktop/laptop space.