Using flash memory as an attack vector

[SteveRiley]

The carrier's stuff happens outside my device.

Carrier stuff also happens on the SIM inside your device.

my commutations are secure

Why does it matter whether the conversion of alternating current to direct current is done securely? BWAHA.

[Feathers McGraw]

Carrier stuff also happens on the SIM inside your device.


Why does it matter whether the conversion of alternating current to direct current is done securely? BWAHA.

Wait, what are we talking about... when you said "carriers" I assumed you meant providers of open WiFi networks?

[SteveRiley]

Wait, what are we talking about... when you said "carriers" I assumed you meant providers of open WiFi networks?

Ah, right. I got tangled up in my own terminology. It would have been more accurate for me to have written "provider" in post #13.

But... in many existing mobile phones, the wi-fi radio also requires proprietary driver blobs. Same for GPS, Bluetooth, NFC, probably others. Check out the list of binary drivers required for Nexus devices. No one gets to see the source code for any of this stuff.

[Feathers McGraw]

Ah, right. I got tangled up in my own terminology. It would have been more accurate for me to have written "provider" in post #13.

But... in many existing mobile phones, the wi-fi radio also requires proprietary driver blobs. Same for GPS, Bluetooth, NFC, probably others. Check out the list of binary drivers required for Nexus devices. No one gets to see the source code for any of this stuff.

Eugh. I used to have a nexus 7 2012 WiFi (grouper) - think you have this one too? - now I have a nexus 7 2012 LTE (deb). I traded up in convenience, it makes a great SatNav, but down in terms of "open" security.

What do you think is the reason for the lack of FOSS WiFi drivers for mobile devices? Are they different to laptop components in some fundamental way, or is or just not worth it to write them because the components change so quickly? Most people I know change phones way more often than laptops.

[SteveRiley]

Eugh. I used to have a nexus 7 2012 WiFi (grouper) - think you have this one too?

I have a Nexus 4, 7 (first gen), and 10. I use the 4 and 10 daily. Hardly touch the 7.

What do you think is the reason for the lack of FOSS WiFi drivers for mobile devices?

To retain control. The Nexus 4 modem SoC has support for LTE band 4. This was supposed to have been disabled by the baseband because the modem didn't receive FCC approval for LTE. Nevertheless, early baseband drivers failed to block access. Later updates have blocked it, but smart people on XDA have developed hybrid radios that combine newer functionality while retaining the exposed LTE band 4.

[Feathers McGraw]

Interesting. I have a feature phone and use my N7 for the things most people use their smart phones for. It's a nice size for a one handed device if you have big hands, and the essential phone bits never run out of battery. Ideal

When I say WiFi drivers, though, I don't mean 3g/4g, I mean plain WiFi... or is there one driver for the whole chip, in the same way that lots of WiFi chips also do Bluetooth?

[SteveRiley]

Yeah, I knew in this case you weren't directly referring to the baseband. Take a look again at that list of binary drivers. Typically, each hardware component row represents a distinct SoC in the device, and the drivers for that SoC come as a single bundle. In the Nexus 5, non-cell communications is handled by a single Broadcom SoC that includes wi-fi, Bluetooth, and NFC. My Nexus 4 is very different -- NFC is an SoC on its own, from Broadcom. Non-cell communications is on a separate Qualcomm SoC, and you can see that SoC does much more than just communications. In fact, some of the early Nexus 4 hackers were rather stumped that changing radios could mess up things like the orientation sensor and camera. Well, now we know why.

Just now, I downloaded and expanded the driver bundle for the Qualcomm SoC in the Nexus 4. It contains several .fw firmware files and many .so shared object files. Nevertheless, it's one integrated bundle specifically for this SoC. If you wanted to write third-party open source wi-fi drivers, you would need to find some documentation on the internal design of the wi-fi element of the SoC. Good luck with that. The people who make these chips are highly protective of their intellectual property. And much like carriers, they would prefer that you throw away your phone every year and buy a new one. Documenting this stuff just means that more people will figure out how to make devices last longer, slowing down the upgrade cycle and reducing revenue.

[Feathers McGraw]

Interesting!

Still strange that we don't have so much of a problem with laptops though, is it partly a matter of space, i.e. putting loads of stuff on one SoC makes for a smaller device?

I stuck NFC in my t440s, thought it would be interesting to play with and a nice way to switch content from tablet to laptop. Pretty sure that's its either its own SoC, or bundled with the fingerprint reader, depending on what you ordered... seems a strange pair, but whatever (I didn't order a fingerprint reader, so the chip I get should just be NFC).

[GreyGeek]

...Check out the list of binary drivers required for Nexus devices. No one gets to see the source code for any of this stuff.

I drilled down on a few. They end up as root owned shell scripts wrapping a EULA and a tar command which unpacks a binary blob IF you accept the license agreement. ANYTHING could be in those blobs, and probably is.

[MoonRise]

Always wondered about that and memory devices as such. Makes sense. Hmmmmm. Achk.

[GreyGeek]

At Long Last -- proof of NSA back door in my Cisco Firmware!

In the spring of 2012 I purchased a Cisco Linksys E2500 wifi to replace my busted Linksys WRT54GL. In late June I got a popup window on my Kubuntu 12.04 asking if I would accept the Cisco license to upgrade the firmware AND complete the registration for a Cisco Cloud Account,among other things. What?

I declined the offer and closed the upgrade app. Then I went hunting for answers. After recently reading about the NSA letters and other assaults on our liberties I began to suspect that the Cisco "upgrade" was more than just an a bug fix or hole patch, but was itself a back door. My suspicion was that the NSA asked/forced Cisco to include a back door for them in a firmware upgrade which would be FORCED upon the user. Their undoing was greed. Cisco probably thought "Why not take advantage of this and force their customers to create a Cisco Cloud account as well?"
http://www.neowin.net/news/cisco-loc...-cloud-service
The TOS of the Cloud account was a requirement for consumers to sign away their Bill of Rights. That caused a firestorm!
http://www.crn.com/news/networking/2...oud-fiasco.htm

When the relevant Cisco firmware update came out, users of Linksys EA3500, EA2700 and EA4500 routers were pushed to a sign-up page for Cisco Connect Cloud instead of the usual password log-in. What sparked the backlash was Cisco Connect Cloud's terms of service

That was strange. The E2500 was not listed among the routers getting the "upgrade".

I wasn't the only one with suspicions:

http://www.wired.com/threatlevel/201...outer-hacking/

The vulnerability Lynn found, in a new version of the operation system that Cisco planned to release at the time, would have allowed someone to create a router worm that would shut down every Cisco router through which it passed, bringing down a nation’s critical infrastructure. It also would have allowed an attacker to gain complete control of the router to sniff all traffic passing through a network in order to read, record or alter it, or simply prevent traffic from reaching its recipient.
Once Lynn found the vulnerability, it took him six months to develop a working exploit to attack it.
Lynn had planned to discuss the vulnerability at the Black Hat security conference in Las Vegas, until Cisco intervened and forced him to pull the talk under threat of a lawsuit.


But if Lynn knew about the vulnerability, there were likely others who did as well — including intelligence agencies and criminal hackers.
Source code for Cisco’s IOS has been stolen at least twice, either by entities who were interested in studying the software to gain a competitive advantage or to uncover vulnerabilities that would allow someone to hack or control them.

So I also learned about Michael Lynn and his Black Hat conference presentation, but after his employer, ISS, forbid him to give it he resigned and gave it anyway. Then, Cisco sued. All you-know-what broke loose. Apparently Cisco hasn't learned anything from 7 years ago, but Lynn got lots of job offers.
http://boingboing.net/2005/07/29/mic...ns-contro.html



I never found solid evidence linking the Cisco firmware upgrade to an NSA back door. Until today!
http://www.bradreese.com/blog/12-30-2013.htm

In a stunning development, Cisco has officially acknowledged for the very first time the real possibility of NSA backdoors implanted within Cisco networking devices as detailed in the newly released Cisco Product Security Incident Response Team (PSIRT) incident ID:
PSIRT-1384943056

Additionally, Cisco senior vice president and chief security officer, John Stewart, blogged:
Cisco Product Security Incident Response Team (PSIRT) has opened an investigation
"Customers can stay informed of the progress of this investigation via the previously posted Cisco Security Response about the alleged capabilities of the United States National Security Agency (NSA) Tailored Access Operations (TAO) organization. TAO 'exploits the technical weaknesses' of Information Technology products from numerous companies, and mentions Cisco. We are deeply concerned with anything that may impact the integrity of our products or our customers' networks and continue to seek additional information."

A "real possibility". They were responsible for building the device and code in the firmware. How can they NOT know what is in it or was added to it?

Regardless, the same day that upgrade message popped up on my desktop and I did some research, I decided that I didn't want a Cisco back door, OR an NSA back door on my wifi. I burned its firmware with the DD-WRT open source wifi firmware Firmware: "DD-WRT v24-sp2 (06/08/12) mini (build 19342)".

Works beautifully. It doesn't mean there still isn't a back door in my Cisco E2500, but Cisco doesn't have access to it any more and neither does the NSA stuff that was in the Cisco firmware upgrade.

BTW, looking at JETPLOW and the other NSA router spyware one notices in the diagrams that they are represented as being "persistant", indicating that they bypass the system bios and Operating System and inserts itself between the OS and the MPU/CPU.

[MoonRise]

Hmmmm. Thanks though you implanted concerns for me. Recently had to get a new modem/router from my ISP and it is of all things a CISCO device. They force you to use CLASS C subnetting. Didn't like that but now don't like it any more.

[Feathers McGraw]

One more reason to use *wrt!

[SteveRiley]

I drilled down on a few. They end up as root owned shell scripts wrapping a EULA and a tar command which unpacks a binary blob IF you accept the license agreement. ANYTHING could be in those blobs, and probably is.

The only thing inside the script file that actually performs work is this line:

tail -n +315 $0 | tar zxv

It means "pass the contents of myself ($0), from line 315 to the end, through tar and expand the files within." The result is a bunch of files in the subdirectory "vendor":

steve@t520:~/junk$ [B]tree vendor[/B]
vendor
├── lge
│   └── mako
│       ├── BoardConfigVendor.mk
│       └── device-vendor.mk
└── qcom
    └── mako
        ├── BoardConfigPartial.mk
        ├── device-partial.mk
        └── proprietary
            ├── a300_pfp.fw
            ├── a300_pm4.fw
            ├── Android.mk
            ├── ATFWD-daemon
            ├── bridgemgrd
            ├── btnvtool
            ├── diag_klog
            ├── diag_mdlog
            ├── ds_fmc_appd
            ├── dsps.b00
            ├── dsps.b01
            ├── dsps.b02
            ├── dsps.b03
            ├── dsps.b04
            ├── dsps.b05
            ├── dsps.mdt
            ├── efsks
            ├── eglsubAndroid.so
            ├── flp.msm8960.so
            ├── gps.msm8960.so
            ├── hci_qcomm_init
            ├── ks
            ├── libacdbloader.so
            ├── libadreno_utils.so
            ├── libaudcal.so
            ├── libaudioalsa.so
            ├── libC2D2.so
            ├── libc2d30-a3xx.so
            ├── libc2d30.so
            ├── libCB.so
            ├── libchromatix_imx111_default_video.so
            ├── libchromatix_imx111_preview.so
            ├── libchromatix_imx111_zsl.so
            ├── libchromatix_imx119_default_video.so
            ├── libchromatix_imx119_preview.so
            ├── libchromatix_mt9e013_default_video.so
            ├── libchromatix_mt9e013_preview.so
            ├── libchromatix_mt9e013_video_hfr.so
            ├── libchromatix_ov5647_default_video.so
            ├── libchromatix_ov5647_preview.so
            ├── libchromatix_ov5647_video_hfr.so
            ├── libchromatix_ov8825_default_video.so
            ├── libchromatix_ov8825_preview.so
            ├── libchromatix_ov9726_default_video.so
            ├── libchromatix_ov9726_preview.so
            ├── libchromatix_s5k4e1_default_video.so
            ├── libchromatix_s5k4e1_preview.so
            ├── libchromatix_vx6953_default_video.so
            ├── libchromatix_vx6953_preview.so
            ├── libCommandSvc.so
            ├── libconfigdb.so
            ├── libcsd-client.so
            ├── libdiag.so
            ├── libdrmdecrypt.so
            ├── libdrmdiag.so
            ├── libdrmfs.so
            ├── libdrmtime.so
            ├── libdsi_netctrl.so
            ├── libdsprofile.so
            ├── libdss.so
            ├── libdsucsd.so
            ├── libdsutils.so
            ├── libEGL_adreno.so
            ├── libgemini.so
            ├── libgeofence.so
            ├── libGLESv1_CM_adreno.so
            ├── libGLESv2_adreno.so
            ├── libgps.utils.so
            ├── libgsl.so
            ├── libI420colorconvert.so
            ├── libidl.so
            ├── libimage-jpeg-dec-omx-comp.so
            ├── libimage-jpeg-enc-omx-comp.so
            ├── libimage-omx-common.so
            ├── libizat_core.so
            ├── libllvm-a3xx.so
            ├── libloc_api_v02.so
            ├── libloc_core.so
            ├── libloc_ds_api.so
            ├── libloc_eng.so
            ├── libmercury.so
            ├── libmmcamera_faceproc.so
            ├── libmmcamera_frameproc.so
            ├── libmmcamera_hdr_lib.so
            ├── libmmcamera_image_stab.so
            ├── libmmcamera_statsproc31.so
            ├── libmmcamera_wavelet_lib.so
            ├── libmm-color-convertor.so
            ├── libmmipl.so
            ├── libmmjpeg.so
            ├── libmmjps.so
            ├── libmmmpod.so
            ├── libmmmpo.so
            ├── libmmstillomx.so
            ├── libnetmgr.so
            ├── liboemcamera.so
            ├── liboemcrypto.so
            ├── libplayback_adreno.so
            ├── libq3dtools_adreno.so
            ├── libqcci_legacy.so
            ├── libqdi.so
            ├── libqdp.so
            ├── libqmi_cci.so
            ├── libqmi_client_qmux.so
            ├── libqmi_common_so.so
            ├── libqmi_csi.so
            ├── libqmi_csvt_srvc.so
            ├── libqmi_encdec.so
            ├── libqmiservices.so
            ├── libqmi.so
            ├── libQSEEComAPI.so
            ├── libril-qc-qmi-1.so
            ├── libril-qcril-hook-oem.so
            ├── librs_adreno_sha1.so
            ├── librs_adreno.so
            ├── libRSDriver_adreno.so
            ├── libsc-a3xx.so
            ├── libsensor1.so
            ├── libsensor_reg.so
            ├── libsensor_user_cal.so
            ├── libstagefright_hdcp.so
            ├── libxml.so
            ├── mm-qcamera-daemon
            ├── mpdecision
            ├── netmgrd
            ├── nl_listener
            ├── port-bridge
            ├── q6.b00
            ├── q6.b01
            ├── q6.b03
            ├── q6.b04
            ├── q6.b05
            ├── q6.b06
            ├── q6.mdt
            ├── qcks
            ├── qmuxd
            ├── qseecomd
            ├── radish
            ├── rmt_storage
            ├── sensors.msm8960.so
            ├── sensors.qcom
            ├── thermald
            ├── tzapps.b00
            ├── tzapps.b01
            ├── tzapps.b02
            ├── tzapps.b03
            ├── tzapps.mdt
            ├── usbhub
            ├── usbhub_init
            ├── v4l2-qcamera-app
            ├── vidc_1080p.fw
            ├── vidc.b00
            ├── vidc.b01
            ├── vidc.b02
            ├── vidc.b03
            ├── vidc.mdt
            ├── wcnss.b00
            ├── wcnss.b01
            ├── wcnss.b02
            ├── wcnss.b04
            ├── wcnss.b05
            └── wcnss.mdt

While weird it isn't all that uncommon. The VMware Player installer for Linux works similarly.

[SteveRiley]

Still strange that we don't have so much of a problem with laptops though, is it partly a matter of space, i.e. putting loads of stuff on one SoC makes for a smaller device?

Indeed. SoCs are the reason why we can have so much computing power in so little space. x86 designs are moving in this direction, sort of. There are fewer chips on motherboards these days because Intel and AMD are consolidating functions.