David A. Wheeler's Blog

Mon, 23 Nov 2015

Ransomware coming to medical devices?

Forrester Research has an interesting cybersecurity prediction for 2016: We’ll see ransomware for a medical device or wearable.

This is, unfortunately, plausible. I don’t know if it will happen in 2016, but it’s pretty reasonable. Indeed, I can see threats.. even if we can’t be sure that the ransomware is even installed.

After all, Dick Cheney had his pacemaker’s Wifi disabled because of this concern (see also here). People have already noted that terrorists might use this, since medical devices are often poorly secured. The additional observation is that may be a better way to (criminally) make money. We already have ransomware, including organizations who are getting better at extorting with it. Traditional ransomware is foiled by good backups; in this case backups won’t help, and victims will (understandably) be willing to pay much, much more. And I think that medical devices are actually a softer target.

With luck, this won’t come true in 2016. The question is, is that because it doesn’t show up until 2017 or 2018… or because the first ones were in 2015? DHS is funding work in this area, and that’s good… but while research can help, the real problem is that we have too many software developers who do not have a clue how to develop secure software… and too many people (software developers or not) who think that’s acceptable.

In short, we still have way too many people building safety-critical devices who don’t understand that security is necessary for safety. I hope that this changes - and quickly.

path: /security | Current Weblog | permanent link to this entry

Fri, 09 Oct 2015

Government adoption of OSS

If you’re interested in open source software (OSS), or in how governments can work better, take a look! Mark Bohannon has posted the article “U.S. report highlights positive elements of government open source adoption” on Opensource.com. This discusses a paper Tom Dunn and I wrote Open Source Software in Government: Challenges and Opportunities, and discusses a few things that have happened since. Enjoy!

path: /oss | Current Weblog | permanent link to this entry

Wed, 30 Sep 2015

Reveloping open source software in Linux Foundation projects: $5 billion and 30 years

The Linux Foundation now estimates it would cost $5 billion and 30 years to redevelop “the software residing in The Linux Foundation’s collaborative projects”. That’s not even all free / libre / open source software (FLOSS). Of course, there are many caveats, but that’s still an intriguing number; it provides a simple view of just how big FLOSS has become. They also credit me, since they applied the same general process I developed earlier in my “More than a Gigabuck” paper. Thanks! If you’re interested in FLOSS, I think you’ll find this paper intriguing.

path: /oss | Current Weblog | permanent link to this entry

Tue, 07 Apr 2015

Heartbleed found with american fuzzy lop (afl) and Address Sanitizer (ASan)

Big news in security vulnerability research: Hanno Böck found Heartbleed using american fuzzy lop (afl) and Address Sanitizer (ASan) - and in only 6 hours of execution time.

This means that software developers should seriously consider using a more-advanced fuzzer, such as american fuzzy lop (afl), along with Address Sanitizer (ASan) (an option in both the LLVM/clang and gcc compilers), whenever you write in C, C++, Objective-C, or in other circumstances that are not memory-safe. In particular, seriously consider doing this if your program is exposed to the internet or it processes data sent via the internet (practically all programs meet this criteria nowadays). I had speculated that this combination could have found Heartbleed in my essay on Heartbleed, but this confirmation is really important. Here I will summarize what’s going on (using the capitalization conventions of the various tool developers).

The american fuzzy lop (afl) program created by Michal Zalewski is a surprisingly effective fuzzer. A fuzzer is simply a tool that sends lots of semi-random inputs into a program and to detect gross problems (typically a crash). Fuzzers do not know what the exact correct answers are, but because they do not, they can try out more inputs than systems that know the exact correct answers. But afl is smarter than most fuzzers; instead of just sending random inputs, afl tracks which branches are taken in a program. Even more interestingly, afl even tracks how often different branches are taken when running a program (that is especially unusual). Then, when afl creates new inputs, it prefers to create them based on inputs that have produced different counts on at least some branches. This evolutionary approach, using both branch coverage and the number of times a branch is used, is remarkably effective. Simple dumb random fuzzers can only perform relatively shallow tests; getting any depth has required more complex approaches such as detailed descriptions of the required format (the approach used by so-called “smart” fuzzers) and/or white-box constraint solving (such as fuzzgrind or Microsoft’s SAGE). It’s not at all clear that afl eliminates the value of these other fuzzing approaches; I can see combining their approaches. However, afl is clearly getting far better results than simple dumb fuzzers that just send random values. Indeed, the afl of today is getting remarkably deep coverage for a fuzzer. For example, the post Pulling JPEGs out of thin air shows how afl was able to start with only the text “hello” (a hideously bad starting point) and still automatically figure out how to create valid JPEG files.

However, while afl is really good at creating inputs, it can only detect problems if they lead to a crash; vulnerabilities like Heartbleed do not normally cause a crash. That’s where Address Sanitizer (ASan) comes in. Address Sanitizer turns many memory access errors, including nearly all out-of-bounds accesses, double-free, and use-after-free, into a crash. ASan was originally created by Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitry Vyukov. ASan is amazing all by itself, and the combination is even better. The fuzzer afl is good at creating inputs, and ASan is good at turning problems into something that afl can detect. Both are available at no cost as Free/ libre/ open source software (FLOSS), so anyone can try them out, see how they work, and even make improvements.

Normally afl can only fuzz file inputs, but Heartbleed could only be triggered by network access. This is no big deal; Hanno describes in his article how to wrap up network programs so they can be fuzzed by file fuzzers.

Sometimes afl and ASan do not work well together today on 64-bit systems. This has to do with some technical limitations involving memory use; on 64-bit systems ASan reserves (but does not use) a lot of memory. This is not necessarily a killer; in many cases you can use them together anyway (as Hanno did). More importantly, this problem is about to go away. Recently I co-authored (along with Sam Hakim) a tool we call afl-limit-memory; it uses Linux cgroups to eliminate the problem so that you can always combine afl and ASan (at least on Linux). We have already submitted the code to the afl project leader, and we hope it will become part of afl soon. So this is already a disappearing problem.

There are lots of interesting related resources. If you want to learn about fuzzing more generally, some books you might want to read are Fuzzing: Brute Force Vulnerability Discovery by Sutton, Greene, and Amini and Fuzzing for Software Security Testing and Quality Assurance (Artech House Information Security and Privacy) by Takanen, DeMott, and Miller. My class materials for secure software design and programming, #9 (analysis tools), also cover fuzzing (and are freely available). The Fuzzing Project led by Hanno is an effort to encourate the use of fuzzing to improving the state of free software security, and includes some tutorials on how to do it. The paper AddressSanitizer: A Fast Address Sanity Checker is an excellent explanation of how ASan works. My essay How to Prevent the next Heartbleed discusses many different approaches that would, or would not, have detected Heartbleed.

I do not think that fuzzers (or any dynamic technique) completely replace static analysis approaches such as source code weakness analyzers. Various tools, including dynamic tools like fuzzers and static tools like source code weakness analyzers, are valuable complements for finding vulnerabilities before the attackers do.

path: /security | Current Weblog | permanent link to this entry

Sat, 04 Apr 2015

Security presentation updates

I’ve updated my presentations on how to design and implement secure software. In particular, I’ve added much about analysis tools and formal methods. There is a lot going on in those fields, and no matter what I do I am only scratching the surface. On the other hand, if you have not been following these closely, then there’s a lot you probably don’t know about. Enjoy!

path: /security | Current Weblog | permanent link to this entry

Fri, 27 Mar 2015

Z3 is OSS!

Z3 has been released as open source software under the MIT license! This is great news. Z3 is a good satisifiability modulo theories (SMT) solver / theorem prover from Microsoft Research. An SMT solver accepts a set of constraints (such as “a<5 and a>1”) and tries to produce values that satisfy all the constraints. A satisfiability (SAT) solver does this too, but SAT solvers can only work with boolean variables; SMT solvers can handle other types, such as integers. Here is a Z3 tutorial.

SMT solvers are basically lower-level tools that have many uses for building larger capabilities, because many problems require solving logical formulas to find a solution.

I am particularly interested in the use of SMT solvers to help prove that programs do something or do not do something. Why3 is a platform that lets you write programs and their specifications, and then calls out to various provers to try to determine if the claims are true. By itself Why3 only supports its WhyML language, but Why3 can be combined with other tools to prove statements in other languages. Those include C (using Frama-C and a plug-in), Java, and Ada. People have been able to prove tiny programs for decades, but scaling up to bigger programs in practice requires a lot of automation. I think this approach of combining many different tools, with different strengths, is very promising.

The more tools that are available to Why3, the more likely it will solve problems automatically. That’s because different tools use different heuristics and focus on different issues, resulting in different ones being good at different things. There are already several good SMT solvers available as OSS, including CVC4 and alt-ergo.

Now that Microsoft has released Z3 as OSS, there is yet another strong OSS SMT solver that tools like Why3 can use directly. In short, the collection of OSS SMT solvers has just become even stronger. There’s a standard for SMT solver inputs, the SMT-LIB format, so it’s not hard to take advantage of many SMT solvers. My hope is that this will be another step in making it easier to have strong confidence in software.

path: /oss | Current Weblog | permanent link to this entry

Wed, 11 Mar 2015

Plans for HTTPS (SSL/TLS) on this site

Currently this website uses only HTTP, and does not support HTTPS. That means that users cannot trivially authenticate what they receive, and that in some cases users reveal to others what they are viewing on the site. (Technical note: HTTPS is implemented by a lower-level protocol; the current protocol versions of this protocol are named TLS, and the older ones are named SSL, but a lot of people use the term SSL to include TLS.) I would like to use HTTPS, but this website is entirely self-funded. I do have a plan, though.

My current plan is that I am waiting for Let’s encrypt to stand up and be ready. Once that gets going, I intend to use it to add support for HTTPS. I’d like to eventually only support HTTPS, since that prevents downgrade attacks, but I need to make sure that the TLS certificates and configuration works well. Also, I pay others to maintain the server; since I am not made of money, I necessarily use low-end cheap services. That will limit what I can do in terms of HTTPS configuration hardening. On the other hand, it should be better than the current situation.

The software I develop is generally available on SourceForge or GitHub, and they already provide HTTPS, so you don’t need to wait for that. Currently you have to log into SourceForge to get HTTPS, but that is expected to change, and for now just log in.

Anyway, I thought some of you might like to know that there is a plan.

path: /website | Current Weblog | permanent link to this entry

Sat, 14 Feb 2015

Learning from Disaster

Learning from Disaster is a collection of essays that examines computer security disasters, and what we can learn from those disasters. This includes Heartbleed, Shellshock, POODLE, the Apple goto fail, and Sony Pictures. If you’re interested in computer security I think you’ll find this collection interesting.

So: please enjoy Learning from Disaster.

path: /security | Current Weblog | permanent link to this entry

Tue, 06 Jan 2015

Cloud security

There seems to be a lot of confusion about security fundamentals of cloud computing (and other utility-based approaches). For example, many people erroneously think hardware virtualization is required for clouds (it is not), or that hardware virtualization and containerization are the same (they are not).

My essay Cloud Security: Virtualization, Containers, and Related Issues is my effort to counteract some of this confusion. It has a quick introduction to clouds, a contrast of various security isolation mechanisms used to implement them, and a discussion of some related issues.

So please check out (and enjoy) Cloud Security: Virtualization, Containers, and Related Issues.

path: /security | Current Weblog | permanent link to this entry