The RISC-V Files: On Princeton MCM and Linus' Law

Princeton and RISC-V MCM

In the past week, a research team from Princeton's school of engineering released details on flaws they uncovered in the RISC-V memory consistency model (MCM). This is exciting work from Professor Margaret Martonosi and her team, because it demonstrates the value of using automation to uncover design flaws in complex systems. 

This strategy may be similar to the techniques used by commercial tools, such as Tortuga Logic's silicon security analysis utilities. Regardless, advances in capability from both commercial and academic teams has exponentially improved the state of the art over recent years. As a result, these bugs are being uncovered faster, and earlier in the engineering (or ratification) process, than ever before. 

Codasip and Linus' Law

To comment on the Martonosi's findings, the Codasip team released a blog post describing their thoughts in the context of long-term RISC-V reliability and security. While I typically agree with the Codasip team, and have a large amount of respect for their engineering staff, I thought it imperative to comment on one aspect of their article: complex security landscapes are not made shallow when more eyes are focused on them. 

This concept, colloquially known as Linus' Law, posits that all flaws in complex (and open) systems are increasingly easy to observe, detect, and resolve as the number of users and engineers of that system increases. While this model does work for quality assurance (stability) purposes, it does not work well for subtleties that impact the security of complex systems. 

While there are many reasons why this mantra fails with respect to security models, I'll focus on one example for the purposes of this blog post: Linus' Law largely implies that bugs will reveal themselves.

Security is Not Stability

Linus' Law presumes one of two things will occur to diminish the total number of bugs in a complex system:

1. Many engineers hunt for flaws in source code
2. A subset of N users out of T total users will observe and report any given bug

While there are hundreds of engineers working on the Linux code base, they are often constrained within the technology they are focused on improving or implementing. Though these engineers can identify problems within their own ecosystem, they are largely focused on the source code of their implementation, not the resultant object code or machine code generated to run their source code, or the effects their code will have (and vice-versa) on multiple aspects of a running system. This level of visbility into a complex architecture is extremely challenging to acquire, and even more challenging to maintain. This is why, while many engineers submit patches to the Linux kernel, only a handful of engineers are authorized to actually approve code for inclusion into each branch of the kernel. Put simply, only a few individuals are capable of observing complex security flaws, and these individuals are largely bogged down by engineering tasks that do not include the overarching analysis of subtle behaviors in the context of security. 

Yet, this point describes bugs that can be found easily prior to inclusion into the release of a kernel version. But, what happens when a bug does get through these checks and balances and ends up in the wild? This is where the many users part of Linus' Law comes into play. Someone, somewhere, out in production, will observe anomalous behavior. Hopefully, this user (or users) will also report this issue to the kernel team, or their distribution maintainers. It's fine to presume this will occur, but this will likely only occur if the bug is actually triggered by the user. 

In the case of complex security flaws, they are almost never triggered in the wild on accident. Exploiting a complex security flaw usually only occurs with intent, not arbitrarily. If one piece of a complex set of bugs leading to a critical gap in system security is triggered accidentally, it may never be observed as a flaw impacting security unless a specific chain of flaws are triggered all at once, and in a particular order. This is highly improbable in the real world, and results in a lot of simple bugs either being ignored as irrelevant, or resolved in the context of stability and not flagged as security related, which affects who applies the patch and how quickly. 

This is why applications like Ubuntu's whoopsie are imperative, to ensure that even the simplest bugs are not ignored. But, it also requires the team reviewing whoopsie bug/crash reports to be capable of evaluating the risk of each flaw, then properly escalating the issue to someone with authority. So, there are still gaps even with this practice in place. 

Thus, as we can see, Linus' Law works well to ensure the stability of complex systems, but it is very inefficient at identifying and guarding users against security flaws. 

That Lonesome Road

The real resolution to complex security related issues is creating a team to perform a unified analysis of each technology used in a system, and the overarching interactions between the technologies that make up the whole system. Using this model, less long-term flaws can make their way into system releases, and the ones that do are more likely to be simple bugs that can be detected using the presumptions in Linus' Law. 

In addition, tools like Professor Martonosi's team's technology, and commercial tools like Tortuga Logic's silicon security utilities, can greatly assist an internal security team, streamlining their workload and reducing errors by optimizing their time. 

This path, however, requires a long-term commitment to security, and an understanding that security is not a separate discipline from engineering, but is an effect of engineering stable systems. This is because a stable system is one that enforces rigid constraints around how data is accessed, stored, and processed. Insecure systems create arbitrary paths around these constraints, reducing the integrity of a system. Thus, any system with reduced integrity cannot be considered a stable system. 

Though it comes at a cost, the positive effects of implementing a security program are long lasting for both manufacturers and consumers, ensuring greater stability and system integrity for not only end-users, but for the global Internet. 

For more information on architectural security analysis, please reach out to Lab Mouse Security. We specialize in architectural security for embedded systems, from wearable IoT, to Industrial IoT, and more! 

Don A. Bailey

Founder and CEO

Lab Mouse Security

@DonAndrewBailey

https://www.securitymouse.com/contact

HeartBleeding An M2M Business Dry

HeartBleeding An M2M Business Dry

UPDATE 04/18/2014: The Nmap project has added support for HeartBleed detection. This will significantly increase the speed at which bad actors can detect and abuse this vulnerability. Conversely, it can also help administrators scan quickly for vulnerable systems!

UPDATE 04/18/2014: I've been alerted to the fact that several MVNOs are seeing a spike in network traffic on certain M2M APNs. They are attributing this to HeartBleed scanning. Please check your APN networks immediately!

In the Age of the Internet of Things, packets are king. By that, I am referring to the monetization of data in the IoT/M2M architecture. Most M2M service providers make money by charging for traffic. Each time an M2M end-point sends or receives data through the cellular network the MVNO makes money, which means the M2M technology company is charged. 

Unfortunately, in the M2M business model, this usually means that the charges trickle down to the user somehow. Do we stop and consider when an end-point or network is being attack, though? This scenario is largely considered an edge case and abnormal event. So, how would it be handled from a financial point of view? Well, that is dependent on the business model of the particular technology. Instead of speculating, let's figure out how a bad actor can use practical M2M attack models to forcibly drain money from the network while retrieving critical tokens using HeartBleed. 

The Lazy Bad Actor

The most obvious model is the unprotected M2M service. This deployment has servers directly accessible via the Internet. Attacking the M2M network in the fashion is simple. An attack against an Internet-accessible service requires no special equipment or code. Many software packages are readily accessible to perform this act, and I'm not going to bother getting into it here. 

The goal is simple. Penetration of the edge-servers allow access to the M2M deployment network. Particular interest would be access to the APN. If SSL/TLS services are active on the Internet-accessible servers, data could be exposed that may allow an attacker to impersonate users or M2M end-points. A simple example of this would be a model where mobile users can interact with their end-points through a smart-phone app. 

Figure 1. The Internet-based M2M Attack Model

If the App sends or receives credentials or session tokens, they could be leaked through abuse of HeartBleed. If this data is recovered through HeartBleed abuse, sessions can be created to impersonate these users. The result? Data will be routed through the M2M network and trickle-down through the APN to the end-points, causing the user or application owner to be charged for data transmissions.

A More Ambitious Attack

A more important model to evaluate is an APN-based attack against the M2M servers. This attack occurs over the cellular network, and typically involves a bad actor obtaining several pieces of necessary equipment: a cellular modem, a SIM or MIM card authorized for the APN. 

Obtaining a cellular modem is a non-issue, obviously. Unlocked GSM/UMTS/etc modems are easy to come by, and easy to use. Anyone can plug one of these devices into their laptop and have instant access to the cellular network. Which cellular network is the key, however. If the bad actor has the name of the APN and the right SIM or MIM, access is simple. 

However, obtaining a SIM or MIM is not as easy. A SIM card for a particular cellular APN must usually be obtained from sample or production equipment relevant to the device the attacker is interested in. For example, in my attack against the A-GPS device Zoombak, I was able to use the SIM card from an activated Zoombak to connect directly to their cellular network. 

Things get even more difficult when a MIM is involved. For those that aren't familiar with them, a Machine Identification Module (MIM) is the same device as a SIM, but in a different form factor. MIMs are designed to be soldered directly onto the PCB of a device. Therefore, to be abused they must be extracted from the PCB. They are typically quite small, and the adjusted form factor means that specialized hardware must be used to turn the MIM into a SIM. Because MIMs and SIMs have the same pins (just in a different form) they can easily be adapted using a bit of wire, solder, and patience. Regardless, this is a bit of an advanced attack as the attacker must have access to a heat rework station (or a hair dryer), a soldering station, and the know-how to rewire a MIM. Not an altogether simple feat. 

Once this is accomplished, however, direct access to the cellular network can be achieved. Because companies do not expect someone to go to these lengths to abuse their equipment or services, the networks are often wide open upon entry. Even if they aren't wide open, servers that are not accessible from the Internet must still be made available. Why? Simple. If you have a SIM or MIM, you are expected to be a piece of authorized equipment. Therefore, services for such equipment to function must be made available. 

Figure 2. The APN-based Server Attack

Now that the attacker has gained access to the APN, they can start to scan the network or flood servers with requests. In the case of HeartBleed, they may be flooding SSL/TLS servers with thousands of requests attempting to access the tokens of other end-points on the network. This is an extremely dangerous attack for several reasons. First, it will immediately cause a spike in network communication which will result in a high amount of charges being incurred. Second, if security tokens can be leaked, they can be used in the attack I will discuss in the next section. 

But, for the moment, lets focus on the money. Most M2M platforms allow you to identify if an end-user or end-point has a sudden spike in network communications. Some of these platforms even allow for disabling a user if a communications spike has gone over a certain threshold. These are great attributes of some popular M2M platforms, and they definitely help mitigate the risk of fraudulent charges due to network abuse. 

Thus, overall, in this model the attack can both be detected and mitigated. We can detect the network flood in real time, whether or not it is indicative of a HeartBleed attack is another story. If it is HeartBleed, the bad actor can be stopped by simply disabling the SIM or MIM's access to the network. Easy breezy, right? Close! 

The one gotcha is a slow and patient attacker. More and more end-points on M2M networks send and receive large payloads of metadata due to the devices, networks, or users they represent. These packets come in bursts, which is why network scans are so easy to detect. If the user mimics a device and leaks HeartBleed data slowly over a period of hours or days, they may be able to stay under the radar.

The Money Pit

The final attack model is the most devastating one. Depending on the M2M environment, HeartBleed can very well compromise the entire platform and cost a massive amount of money. How? It's actually pretty simple. Most M2M networks are centralized at the cellular link. What this means is, when you're connected to the APN, you're essentially in a private little cloud network. All end-points on the network will communicate through that APN. This means that potentially hundreds of thousands of devices all land on the exact same network at various times throughout the day. 

This was the case for both my Zoombak compromise and the compromise of the car security module in 2011. Both systems, per standard M2M architecture, resulted in every device in the United States landing on the exact same APN network. Why is this important? A set of servers on that APN will manage connectivity for every device. That means that if you are on the APN, you have direct access to these servers. What do they all use for communication? SSL/TLS, that's what. 

So if you know that hundreds of thousands of targets are going to land on the network at one time, you only need to compromise HeartBleed on one or more servers to slowly leak the communications tokens for a large percentage of devices on the network. 

Figure 3. Attacking M2M End-Point Devices

Sure, this is similar to the second attack presented above. It's about to get much more interesting. Why? The credentials captured via HeartBleed can often be used to speak to the end-point devices themselves. In other words, tokens captured through HeartBleed attacks can result in the impersonation of the server against the M2M end-points. Of course, this depends on the security of the actual devices. If the M2M architecture includes signed data for every application-level message, this attack wouldn't work. But, this architecture is not feasible (or necessary) for most deployments. It isn't reasonable to have small embedded devices performing CPU-intensive public-key operations on every message. Instead, a session token is most often used. Why? Because the communications link is secured by SSL/TLS, of course!

So now that people have proven that SSL private keys can indeed be leaked from a vulnerable web server, server-side verification in an isolated M2M environment is problematic. If the attacker can leak both the private key and session tokens, it's game over. Even if the MVNO can detect that an attack is in progress, it may be too late to do anything. 

In the above figure, we can see that messages can be sent from a laptop to end-devices through the APN. With the correct keys (private key and session token) the bad actor may be able to reconfigure devices, "upgrade" firmware, or simply gain remote code execution. Once this occurs, it's game over for the network. Why? You can no longer isolate the attacker. There is no way to know which devices are compromised without individual inspection and you cannot shut down the entire network. 

At this point, the operator is simply playing Whack-A-Mole against an attacker that has transparency and mobility throughout the entire APN. Game over. If desired, the attacker can flood the cellular APN from every compromised device, causing a massive spike in the amount of money charged to the M2M owner. Certainly the end-user cannot pay for the network's failure to contain a risk. Thus, the business deploying the M2M system will take on potentially damaging costs. Depending on the level of compromise, the MVNO/Carrier may even choose to reevaluate whether a device should continue to be allowed on the cellular network. This could be the critical one-two punch that takes down an entire business. 

 Mitigating Risk

Aside from the obvious audit to evaluate whether OpenSSL (or another vulnerable library/package) is being used on the M2M network, more must be done to ensure consistency on the network. An architecture review should be performed to identify how to contain a risk in the event of an edge-case such as HeartBleed. While many administrators and executives see HeartBleed as a rare scenario (and it is) it is absolutely not the only instance of this level of compromise. Although, in my opinion, it is the best example of widespread memory leak. That's a completely separate blog post, however. 

At Capitol Hill Consultants LLC, we specialize in architecture level security. We can quickly identify how to isolate or remove a critical risk in a core component such as OpenSSL, ensuring that the network, your end-users, and end-points, are not at risk. We can also help build simple metrics using existing data to determine whether an attack of this kind is being performed in real time. Scripts and apps can be integrated into existing alerting systems, or out-of-band security channels, improving the reaction time to critical threats. 

For more information, please reach out to our team via our website. 

Best,

D

Blues for SSL

Blues for SSL

UPDATE 4/11/2014 @ 13:47 Mountain: Matrix has released version 3.6.1 to address the integer underflow bugs I found. Find the update here: http://www.matrixssl.org/news.html

UPDATE 4/09/2014 @ 20:51 Mountain: Matrix has acknowledged the bugs I've found and are formulating the appropriate patches. Stay tuned! These guys are quick! :-)

UPDATE 4/09/2014 @ 20:06 Mountain: Matrix and I are in contact. Quick response from them!

Even if you've been hiding under a rock for the past week, #HeartBleed has certainly found you. I had no intention to get involved, mostly because I have great respect for Neel Mehta that goes back years before his tenure at Google. Everything that needed to be said about this vulnerability was said. A lot. Too much, really. 

People have been flooding the TwitterFaceTumblerNets with screengrabs galore, rife with the champion hexadecimal dump, the solace of the SESSIONID mined from binary blobs. Ah, yes, it was a nightmare and a field day for techies everywhere. But, for guys like me, guys a lot lamer than they used to be, it was a pass-over. The necessary work had been done, and I had no business breaking any "cryptographically stone hearts" or wiping the blood of servers over their door. 

But, today, on my way to a finance meeting, it occurred to me that there was one thing left to prove. Embedded systems, to me, posed the greatest risk to Internet stability with respect to Heartbleed. As an Internet of Things enthusiast, I was concerned, and then relieved, by the architectural decisions of the engineers at various top-down IoT firms. It was likely that things were on the up-and-up. But, like I said, there was one thing left to prove. 

When I got home, I quickly audited the three most popular SSL implementations for embedded systems. Wolf/Cya, Polar, and MatrixSSL were all on the menu. The feast was short, unfortunately, because none of these implementations even bothered with the TLS Heartbeat extension. I had work to do, so I let these sleeping dogs lie. 

Then, I was shot with sudden inspiration: What if the bug had nothing to do with Heartbeat, itself? But, was - as we often see in information security - the larger issue of dealing with integers and memory buffers in the C language. Of course that was the problem! Why did I ever feed into the sensationalist bullshit that it was one single extension. 

So, I looked back at the MatrixSSL implementation. What did I see? Right off the bat, integer issues were indeed suspect. 

In the example below, the MatrixSSL source code correctly ensures that the size of the message buffer is suitable for the extension and its attribute size. There are two primary locations where this code comes into play. First, the entirety of the Extension buffer is checked at line 1969 in sslDecode.c. Feel free to follow along in the open version of MatrixSSL released earlier this week. 

                                extLen = *c << 8; c++; /* Total length of list */
                                extLen += *c; c++;
                                if ((uint32)(end - c) < extLen) {
                                        ssl->err = SSL_ALERT_DECODE_ERROR;
                                        psTraceInfo("Invalid extension header len\n");
                                        return MATRIXSSL_ERROR;
                                }
                                while (c != end) {
                                        extType = *c << 8; c++; /* Individual hello ext */
                                        extType += *c; c++;
                                        if (end - c < 2) {
                                                ssl->err = SSL_ALERT_DECODE_ERROR;
                                                psTraceInfo("Invalid extension header len\n");
                                                return MATRIXSSL_ERROR;
                                        }
                                        extLen = *c << 8; c++; /* length of one extension */
                                        extLen += *c; c++;
                                        if ((uint32)(end - c) < extLen) {
                                                ssl->err = SSL_ALERT_DECODE_ERROR;
                                                psTraceInfo("Invalid extension header len\n");
                                                return MATRIXSSL_ERROR;
                                        }

In the above code snippet, we can see the correct evaluation of the extension length. But, what's missing? Ah, yes. It's validating that the extension size doesn't exceed the boundary of the buffer, but it doesn't validate that the size is sensible. In other words, is the value large enough to hold information? That's also an issue that C coders often miss when dealing with buffers. 

As a result, the MatrixSSL code is indeed vulnerable to abuse. It is not even remotely similar to the level of importance attributed to the OpenSSL bug. But, this one deserves a high priority. I have reached out to the MatrixSSL support team and will provide them with the details of the attack as soon as they get back to me. When they provide a fix, I'll discuss on this blog exactly what the results of this issue would be.

NOTE FOR CLARITY: There is a lot more to the vulnerabilities I uncovered today than the code snippet above. My job isn't to leak that information, though anyone with a strong C auditing background can recreate what I've found based on the provided data in this post. I'm only publishing this because of the fast and positive communication I've had with the MatrixSSL team. I have no intention to expose the details of the bugs until they are patched. 

Best,

D

Abusing WiFi-Based A-GPS To Achieve Extreme Low-Cost Targeted Tracking

When security consultants and analysts consider the use of modern-day tracking techniques, they think of two things: tracking devices and mobile phones. And that's fair. GPS tracking devices, such as the Zoombak, are cheaper and more effective than ever before. However, as I demonstrated in 2011, tracking devices are often poorly designed, easy to reverse, and insecure. This means that they can not only be found remotely, but they can be hacked.

Mobile phones are always a significant vector for location tracking, as they commonly move with a target. But, what if the target is only exposed while using a burner? The MSISDN or software on the mobile endpoint may not persist beyond exposure, making the endpoint a less desirable resource.

Advances in technology, however, provide an interesting alternative to these solutions that has not yet been widely discussed by privacy advocates. Though, the pieces of the puzzle have been available for some time. A significant decrease in the cost of microcontrollers (uC) and wireless components, coupled with the increase in use of peripheral technology, provides an interesting vector for abuse.

What if, for a couple of dollars, a tiny device could be constructed that allows for targeted tracking? This article describes a simple example of how and why this is possible.

The Wireless Photograph

An interesting device crossed my path on Woot in the past few months: the Eye-Fi. This product is a simple SD memory card, like you would use with any digital camera. Models are offered that support flash storage of 4GB to 16GB, along with a more interesting storage option: wireless image delivery.

Eye-Fi 802.11 enabled SD Card

At 3.3V, the Eye-Fi product line integrates three chip components: a microcontroller, a flash chip for image and application/configuration storage, and a Marvell 802.11 wireless chip. The internal layout of the product can be seen in this FCC filing from 2010. From this information, it is easy to determine that the Eye-Fi is meant to act as a wireless client driven by the power of a digital camera.

When the camera saves an image to the Eye-Fi, the Eye-Fi SD card transparently uploads the image over a WiFi network to a laptop, phone, or other endpoint on the same network. While gimmicky as a SD card, this product is exceptionally inventive because of the way it exploits power from a host device.

Alternative Use Cases

While writing to the network is certainly an important feat, an aside to this article would be the use of this design for fuzzing/testing of devices that read from an SD card (such as a firmware update). Reads from the SD card could be cached from the network in order to test multiple variations of a firmware image without the chore of having to copy each new image to an SD card. I'm looking at you Travis Goodspeed.

Assisted GPS and WiFi

Regardless, the design of the Eye-Fi brings to mind another technology: Assisted GPS (A-GPS). A-GPS helps devices determine their approximate physical location even when a Global Positioning System (GPS) beacon is unavailable. As many technologists know, A-GPS has evolved beyond the analysis of cellular beacons for location derivation. Today, alternative signals can be used as location control as well, such as 802.11.

Google Street View Car in Action

I'm sure that everyone remembers Google's trouble with WiFi, Street View, and Privacy. Google, along with many other companies, use WiFi to ascertain the physical position of a mobile device when GPS is no longer available. This means that they were collecting a giant database of WiFi access points across several countries around the world. 

Samy Kamkar, a security researcher, came up with a brilliant application that abused Google's web API  and allowed anonymous users to query for 802.11 access points. Google responded by blocking Samy's application and restricting queries to only users that are known to be associated with particular access points.

The Access Point That Wasn't

So, let's presume users can't query devices that they aren't associated with. I'm sure this is hardly the case as even if Google has solidified this issue, custom databases like Zoombak's, Skyhook, and others, have had similar issues to Google's but are far less vetted by the security industry. Regardless, let's step back for a minute and presume this "hole" is patched. What does a researcher do? 

Well, systems like Skyhook and Google don't actually attempt to log on to random WiFi access points. Instead, they simply take note of the location of the beacon along with the access point name (SSID) and the address (MAC/BSSID). This means that the access point (AP) doesn't have to function. In fact, it doesn't have to do anything except emit a valid beacon. 

What if technology similar to the Eye-Fi could be designed to emit a fake AP beacon instead of acting as a client? The "Fake-Fi" could simply emit a beacon intended to be picked up by devices that would pass on the beacon name and MAC to another authority, such as a Google location database.

Selecting a WiFi network on Android

For example, Android and iPhone devices that see the beacon could upload data describing the Fake-Fi access point to a centralized database. This means that everyone in range of the Fake-Fi is helping tell the world where this beacon is located. This makes for an interesting tracking opportunity without having to use a large amount of power, cellular infrastructure, or other complicated technologies. The Fake-Fi can be driven with two simple chips (a uC and an 802.11 chip) off a 3.3V power source for the cost of dollars, just like the Eye-Fi.

The Result

Using this methodology, researchers can poison technologies that are more likely to stay present on an individual's person. A USB cable, USB dongle, mouse, mini-keyboard, laptop power adapter, wall wart, or another commonly trafficked device can now become a beacon.

This is an extremely hard to detect attack as the components used are small and thin enough to fit on a SD Card. There is a large amount of potential host technologies for this technique and few ways to effectively detect them. A user may notice the addition of a WiFi access point in their range, but will they presume it originates from their own equipment, or will they presume a neighbor is the source of the beacon? An attacker can diminish the potential for inspection by lowering the beacon strength of the wireless signal, making it look as if the source is farther away than it actually is.

A common Samsung microSD Card in an Android phone

The SD card in a user's Android phone can even be replaced with this technology, turning the phone into a proxy for the tracking beacon without the user's knowledge. How's that for parasitic technology?

Read and Store

An alternative and purely passive methodology would be to use almost the exact same formula as the Eye-Fi technology: WiFi client. Except, instead of connecting to WiFi networks, the software on the uC could simply log the access points and their frequency to the flash storage. Access points with higher frequency (occurrence) would identify a user's location and could be searched for using the same technologies: Google, Skyhook, etc. 

However, this purely passive tracking technique would require physical access to the target's devices at two exposure points in time, rather than one, significantly increasing the risk of the operation. 

The Take Away

At Capitol Hill, we believe that desktops, laptops, and even BYOD, are no longer the only risks a group or individual must monitor. Instead, security analysts must consider the applicability of each potential wireless endpoint as a source for malicious or parasitic behavior. And, analysts must consider that not all devices are known - or can be known - in a particular environment.

Discovering, cataloging, and isolating, the risks of the wireless world is a growing challenge. At Capitol Hill, we help organizations identify and mitigate the risks introduced by the Bring Your Own Radio world through our years of embedded engineering and security expertise. Our team will help define what practical threats mean to your organization, how they can be detected, and the most fiscally effective ways of removing these risks. Contact us today to determine if our services are right for your organization at: info at capitolhillconsultants dot com.

Best,
Don A. Bailey
Founder