Skip to content

htpasswDoS: Local Denial of Service via Apache httpd password hashes

Apache logoThe way the Apache httpd web server handles password hashes can be abused by a malicious user on a server to cause resource exhaustion and denial of service of the web server. I reported this a while ago to the Apache security team - which led to a lengthy discussion where I was a bit appalled about some of the statements I got from the Apache developers. They can be summed up in a way that major use cases of Apache - especially in web hosting environments - are not recommended by their developers.

Apache supports HTTP basic authentication, a simple login mechanism with username and password that is part of the HTTP protocol. This can be configured via the .htaccess file on a web server. A very simple htaccess file looks like this:

AuthType Basic
AuthName "privat"
AuthUserFile /home/user/pass
require valid-user

The file "/home/user/pass" is a file containing usernames and password hashes. It can be created with the htpasswd tool. It supports several different password hashing schemes. An entry looks like this:


bcrypt hash with insane running time

By fuzzing htpasswd I recognized that some inputs would cause a very long running time of the application. This was caused by bcrypt hashes with a very long computing time.

The hash above uses the bcrypt hash function, indicated by the $2y. The number after that - the $05 - indicates the computing time of the hash function. It can have values between 04 and 31. The purpose of password hashing function is to make brute force attacks slow in case of a breach. Therefore it is desirable for password hashing functions to be slow (which is a very different requirement from many other use cases, where hash functions should be fast). However they also can't be too slow, because they still have to be calculated once for every login attempt.

A user who wants to cause disturbance on a server can now choose to set the computing time of the hash to an insanely large value. The hash value doesn't have to make any sense for this. A user can simply create a password file and change the 05 to 31:


For every login attempt with the right username the server will calculate the hash. The running time of bcrypt doubles with every increase of the computing time value. On my system calculating a hash with the maximum value 31 takes around 30 hours. Therefore with this a user can cause a server process to consume lots of resources for more than a day.

Two things are notable about the Apache behavior here:
  • The hash calculation is neither limited by a connection timeout or by a termination of the connection. Once a connection tries to log in the hashing starts and won't stop even if the user closes his browser.
  • The calculation happens within the server process. In common configurations this means it is not owned by the user, instead it's running under a system-wide user for the httpd server. Apache has functionalities to make sure that user scripts can only be executed under their own user account (SuExec), but these don't matter for the password hashing. This means any resource limit the server administrator has applied to the user account is irrelevant here.

So in summary a user that has the ability to host content on a server is able to severely slow down the whole server for more than a day with a single http request. This can only be stopped by restarting the server. For an administrator it will be nontrivial to figure out what's going on, because he'll only see a server process running amok, he won't have any easy way to trace that back to a user account.

Obviously the malicious user can also open multiple connections, but in my tests at least this didn't cause more resource exhaustion, so it seems all password hashing jobs were processed by the same Apache process. It will probably run longer, but I haven't investigated that in detail. This behavior may differ depending on the server configuration.

As an easy fix I proposed to the Apache developers to limit the computing time of the bcrypt hash. While a slower password hash can be a security improvement, there is no reason to have a hash function that runs longer than a few seconds at best. Here's a patch against apr-util - the package that contains Apache's bcrypt function - that will reject computing time values larger than 17. On my system that runs for 8 seconds, which some may argue is already too much. But it will prevent very simple DoS scenarios.

Is Apache inherently unable to protect against malicious users?

The Apache developers mostly rejected the notion that this is a security problem or any problem at all. I got statements that argue that Apache is inherently unable to defend against a user DoS'ing the server if a user is allowed to use .htaccess and that server operators shouldn't give untrusted users access to configuration files.

This is notable, because the ability to allow users a certain kind of configurability via .htaccess is actually a very distinctive feature of Apache and is widely used in shared web hosting environments. It has lost a lot of market share to Nginx in the past years, yet one of the major reasons some people don't want to switch to Nginx is that it has no comparable feature. In essence I get the feeling that the Apache developers consider the one feature that distincts them from many competitors as being inherently dangerous and discouraged.

One concern that was raised by one of the Apache developers was that even if the bcrypt password hash is capped in its execution time a user can do the same thing via password hashes supported by the C standard library. Apart from its own implementations Apache supports all password hashes provided by the crypt() function. However the concern here is much smaller. The maximum one can achieve is a running time of several minutes with the SHA512-based password hash and 999,999,999 iterations. I submitted a patch to Glibc that limits the execution time to a sane value (no reaction in the bug report yet).

To my surprise the musl libc already capped the running time of the SHA256 and SHA512 password hashing functions - and the code comment by Rich Felker explicitly mentions that this was done to avoid DoS.

Another issue that was raised and that I haven't investigated further is that a user could cause a similar denial of service by creating a crazy regular expression in the .htaccess file (the mod_rewrite functionality supports regular expression, see also Regular expression Denial of Service - ReDoS).

Separating from other issues

I want to point out that there are other security issues that shouldn't be confused with this one. There's an issue with hash table implementations named HashDoS (see this 29C3 talk) that can cause very slow running times of hash tables. It sounds similar, but it's a very different issue.

Another issue is the run time of password hashes for long inputs. Especially the SHA512-based password hash supported by glibc is exposed to this, because its running time grows quadratically with the size of the input. OpenSSH recently has restricted the password length to 1024 characters. There are probably other applications affected by this. Yet again this is a different issue.

Conclusion and comment

While the Apache developers were unwilling to accept that this is a potential security issue, they eventually patched it (the patch is incomplete, but we'll sort that out). So it will be fixed eventually.

The problem highlights several issues. It shows that the user permission concept of Apache is quite questionable. A user has a lot of control over the operations of a server - this also leads to other security problems in multi-user settings that are very hard to avoid. Ideally all user-controlled actions should run under the user account. This can be achieved with the nonstandard mpm-itk, but it can't properly handle use cases where different hosts are accessed over the same connection. It also seems non-ideal that server processes can execute code that can continue to run for hours after a connection has been terminated.

Apart from the specific issue in Apache the idea of abusing password hashes for Denial of Service might work in other settings. It can be applied everywhere where a user is in control of the hash of his password. Commonly this is not the case, but it would be worthwhile to investigate whether there are similar situations.

I've published some proof of concept examples here.

Logo source, Copyright: The Apache Software Foundation, License: Apache License, Version 2.0

Fuzzing Irssi with Perl Scripts

When using fuzzing tools like afl a common challenge is how you can pass input to the interesting parts of the application you want to fuzz. In easy situations we have a tool that will accept our input as a file or via stdin. However sometimes this is not easily possible.

Let's have a look at Irssi, an irc chat client. The only input you can pass on the command line is a config file. Fuzzing Irssi 0.8.10 easily led to a segfault caused by a null pointer access. However while bugs in config file parsers probably still should be fixed, usually they are not very interesting. (There can be exceptions.)

So what else might be interesting? Irssi does some parsing on all output, e.g. due to color codes. However we can't just print text that is passed via the command line as an input file. We have to abuse Irssi's perl scripting capability for that.

We can place a simple perl script that will read a file (fuzzp.txt) and print it into Irssi's autorun directory (default location is ~/.Irssi/scripts/autorun/). We can then place some examples of Irssi color codes into the directory "in/". I have installed an afl/asan-instrumented Irssi into my system to /usr/local/, because for running perl scripts it needs more than just the executable. So we can run afl like this:

afl-fuzz -i in -o out -m none -f fuzzp.txt Irssi

afl will put the fuzzed output into fuzzp.txt and our autoload script will read it from there. Doing this lets us learn that the sequence "%[" causes Irssi to read an invalid memory byte. For reasons unclear to me this only happens if a script outputs this sequence, not if a user types it in. (This issue got CVE-2017-5196 assigned.)

We can go further and do a similar script that executes input as a command. Commands are things like "/QUIT" that control the application and the channel behavior. I named the input file fuzzc.txt, so we can place some simple Irssi commands into in/ and run:

afl-fuzz -i in -o out -m none -f fuzzc.txt Irssi

Thus we will now fuzz Irssi's command processing.

As we have seen, scripting functionality can be used to fuzz an application. So if you want to fuzz something and don't know how to pass input: See if there's a scripting functionality.

Irssi has issued a security advisory for several security vulnerabilities, including the out of bounds read mentioned above. All vulnerabilities and the config file parser segfault are fixed in 0.8.21 and 1.0.0.

Update on MatrixSSL miscalculation (CVE-2016-8671, incomplete fix for CVE-2016-6887)

I recently reported how I found various bugs in the bignum implementation of MatrixSSL, some of them leading to remotely exploitable vulnerabilities.

One of the bugs was that the modular exponentiation function - pstm_exptmod() - produced wrong results for some inputs . This wasn't really fixed, but only worked around by restricting the allowed size of the modulus. Not surprisingly it is still possible to find inputs that cause miscalculations (code). I reported this to MatrixSSL on August 1st.

Recently MatrixSSL released another update (3.8.6) fixing several vulnerabilities reported by Craig Young from Tripwire. However the pstm_exptmod() bug is still there. (The incomplete fix got assigned CVE-2016-8671.)

It is unclear how exploitable such bugs are, but given that it's used in the context of cryptographic functions handling secret key material this is clearly a reason for concern.

MatrixSSL has long advertised itself as a safer alternative to OpenSSL, because it didn't suffer from the same kind of high severity bugs. I think it has been sufficiently shown that this was due to the fact that nobody was looking. But what's more worrying is that bugs they knew about for several months now don't get fixed properly.

Out of bounds heap bugs in glib, heap buffer overflow in gnome-session

By testing GNOME-related packages with Address Sanitizer I recently discovered several trivial to find bugs.

Two out of bounds bugs in the glib library were uncovered by running the test suite with Address Sanitizer enabled. One heap buffer overflow in the parameter parsing of gnome-session was uncovered by trying to start GNOME. Given that these bugs weren't discovered earlier means that most likely nobody ever used Address Sanitizer to test GNOME components.

I strongly recommend to GNOME and to other software communities to use Address Sanitizer testing in order to improve the quality of their software.

Out of bounds read in g_unichar_iswide_bsearch() / glib
Upstream bug report (again reported here)
Commit / fix
Fixed in 2.48.2.

Out of bounds read in token_stream_prepare() / glib
Upstream bug report
Commit / fix
Fixed in 2.48.0.

Heap buffer overflow in gnome-session
Upstream bug report
Commit / fix
Fixed in 3.20.2.

Multiple vulnerabilities in RPM – and a rant

Last year in November I decided that it might be a good idea to fuzz the parsers of package management tools in Linux distributions. I quickly found a couple of issues in DPKG and RPM. For DPKG the process went very smooth. I reported them to Debian's security team, eight days later fixes and security advisories were published by both Debian and Ubuntu, the main distributions using DPKG. For RPM the process was a bit more difficult.

If you want to report a bug to RPM you first may wonder where to report it. The RPM webpage [1] is a trac installation which has its own bug tracker. However if you try to register an account there you'll get forwarded to an HTTPS site with an expired certificate that doesn't match the domain name. In case you are brave and tell your browser to ignore all warnings you'll be greeted by a broken-looking trac without any CSS. Should you proceed and create an account you will learn that this doesn't help you, because in order to be allowed to report a bug you first have to ask on the mailing list or in the IRC channel for permission [2]. That's probably the point where many well-meaning bug reporters give up.

Okay, but RPM originally stood for “Red Hat package manager” (I've been told that today it stands for RPM Package Manager), so maybe Red Hat feels responsible. So I reported three bugs with sample files triggering them to the Red Hat security team on November 20th. The answer was – to put it mildly – a bit dissatisfying. I'll just fully quote it: “Thanks for the report. We also received about 30+ crash reports in RPM from
a different reporter recently so processing all of them (yours and the
others) will take quite a bit of time. We simply don't have the resources
to spend hours upon hours analyzing all crash reports.”

Okay, so I wasn't the only one fuzzing RPM and the maybe bugs will be fixed some day. I waited. In the meantime I got contacted by another person who also had tried to report fuzzing bugs in RPM and who has made similar experiences (maybe the same person who reported the 30+ crashers, I don't know).

In February I decided to ask what the state of things is. I also gave them a 30 day period until I'd publish the bugs (I know that it's now long past that, I shouldn't have let this issue wait so long). I ended up having a call with a Red Hat security team member and exchanged a couple of mails. I learned that RPM has a Github repository [3], which contains fixes for some (but not all) of the issues I reported, however that's nowhere referenced on its webpage. I then fuzzed the current RPM git code again and found two more issues I also reported to the Red Hat security team.

Status today is that the latest release of RPM on its webpage – - is from July 2015, so all of the bugs still affect this release. However it seems there is an unofficial 4.13 release that's nowhere to be found on the RPM webpage, but Red Hat is using it together with some fixes [4]. And the Github repository says the latest release is 4.12.0, so according to three different sources three different versions are the current one (4.12.0,, 4.13).

One of the bugs – a stack overflow (write) - is still present in the latest code on Github.

Commend and Conclusion

This blog post probably reads like a big rant about how unprofessional Red Hat is in handling potential security issues. But this is contrary to my usual experience. I often see Red Hat developers being very active in the free software security community and often contributing in a positive way. Quite simply I expect better from Red Hat. This is not some dubious Enterprise vendor where I wouldn't be the least bit surprised of such a reaction.

The development process of RPM seems to be totally chaotic, it's neither clear where one reports bugs nor where one gets the latest code and security bugs don't get fixed within a reasonable time.

There's been some recent events that make me feel especially worried about this: An unknown person has created an entry in the Libarchive issue tracker [5] that points to an anonymous document [6] with a very detailed description of various security weaknesses in the FreeBSD update process (most of them are still unfixed). The most worrying thing about this is however that the anonymous post mentions the existence similar documents affecting multiple Linux distributions. These documents haven't shown up publicly yet and given the unclear nature of this incident it's hard to know whether they ever will become public or exist at all. But this should still be reason enough to have a closer look at potential security vulnerabilities in all pieces of Linux package management systems.

I haven't analyzed the RPM installation process in detail, so I can't say how likely it is that the RPM tool ever sees a malformed input file. It seems downloads happen over HTTP, but the first thing that happens is a signature check. As the signature is part of the RPM file it already needs to be parsed for this. The exact impact of these bugs would require further analysis. But independent of how likely this is I think the parser in such a crucial piece of software should be robust. It should be safe to use the rpm tool to show info about a file on the command line.


All bugs were found with the help of american fuzzy lop. Here are the bugs:

Stack Overflow in glob() / rpmglob.c.
Sample file (test with rpm -i [input]):
Unfixed in the current Git code.

Heap out of bounds read in headerVerifyInfo() / header.c.
Sample file (test with “rpm -i [input]”):
Git commit:

Null pointer access / segfault in stringFormat() / formats.c
Sample file (test with “rpm -i [input]”):
Git commit:

Out of bounds read in rpmtdGetNumber() / rpmtd.c
Sample file (test with “rpm -qi -p -- [input]”)
Git commit:

Finally one annoying thing to admit: In my original report I included another segfault in headerVerifyInfo() with unclear reasons. However I am now unable to reproduce this one. It may be due to compiler options, different command line parameters or dependencies on my system that have changed. For completeness I'm still providing the sample file:
(Ideally the RPM developers should include all those sample files in a test suite they regularly run against an address sanitizer build of RPM.)

Please also note that I expect this list to be incomplete and there are likely more issues that could be uncovered with further fuzzing. I'll test that once all the existing issues are fixed.

Fun with Bignums: Crashing MatrixSSL and more

If you've been following my fuzzing work you will be aware that I've fuzzed various bignum libraries and found several bugs by comparing implementations against each other.

I recently had a look at the MatrixSSL's modular exponentiation function, for reasons I'll explain later. I wrote a wrapper, similar to previous experiments, comparing its result to OpenSSL.

I immediately noted that the pstm_exptmod() function of MatrixSSL has certain limitations that weren't documented. If one tries to calculate a modular exponentiation with the base equal to the modulus (a^b mod a, code) it would return an error. If one tries to calculate a modular exponentiation with the base zero (0^b mod a, code, CVE-2016-6885) it would crash with an invalid free operation, potentially leading to memory corruption.

In normal cryptographic operations these values should never appear. But these values are in many situations attacker controlled. One situation is during an RSA key exchange. What happens here is that a client encrypts a random secret with the server's key. However a malicious client could simply send a zero or the key's modulus here. I created a patch against openssl that allows to test this. Both values crash the MatrixSSL server. However the crash seems not to happen in pstm_exptmod(), it hits another bug earlier (CVE-2016-6886). In both cases the crash happens due to an invalid memory read in the function pstm_reverse(), which is not prepared for zero-sized inputs and will underflow the len variable.

The crashes have been fixed in 3.8.4, but the pstm_exptmod() function still doesn't accept these inputs. However it no longer crashes with a zero base. It may be possible that these issues can be triggered through other code paths. I haven't tested Diffie Hellman key exchanges, which also allows putting attacker-controlled values into a modular exponentiation.

This is an interesting class of bugs. Bignum functions often aren't designed to handle all inputs and only consider values that make sense in the context of the cryptographic operations. However if they are attacker-controlled this may lead to problems. I just discovered a somewhat similar issue in Nettle. They switched their RSA implementation from GMP's mpz_powm() function to mpz_powm_sec(), which is supposed to be sidechannel resistant. However mpz_powm_sec() is no drop-in replacement. Unlike mpz_pown() it doesn't accept even moduli and crashes with a floating point error. Therefore when trying to use a specifically crafted RSA key with an even modulus this will crash. Fortunately this was discovered before the change made it into a release.

But back to MatrixSSL: Independent of these corner case values that lead to failures I was able to identify an input value that caused a wrong calculation result (code,CVE-2016-6887.

There's a particularly severe risk with calculation errors in the modulo exponentiation when it comes to the RSA algorithm. A common way to speed up the calculation of RSA signatures is an algorithm based on the chinese remainder theorem (CRT) that splits it up into two smaller calculations. However if one of these calculations goes wrong an attacker can learn the private key. Last year Florian Weimer observed that various devices had this error and he could extract their keys. He recently mentioned on the oss-security mailing list that he also observed this in devices using MatrixSSL.

The way the MatrixSSL team "fixed" the miscalculation issue is not really satisfying: They now restrict the input to the pstm_exptmod() function to a set of bit sizes (512, 1024, 1536, 2048, 3072, 4096). My test input had a different bit size, therefore I cannot reproduce the miscalculation any more, but the underlying bug is most likely still there. I've tried to find inputs matching these restrictions and still causing wrong results, but without success yet. Independent of that the restriction means that connections to sites with unusual key sizes or Diffie Hellman moduli will no longer work. While they are not common, there is no rule that RSA keys or Diffie Hellman moduli need to have certain sizes.

Despite the fact that the bug may be still there the CRT attack will probably no longer work. A protection mechanism against that was implemented in version 3.8.3.

I got told by the MatrixSSL developers that their bignum code is based on libtommath. Therefore I also checked if the same bugs appeared there. That wasn't the case. The test input causing wrong results in MatrixSSL were correctly calculated by libtommath and it was also capable of correctly using a zero base or a base equal to the modulus.

Multiple issues in p7zip

I reported several bugs discovered with afl in p7zip, the portable command line version of the 7-Zip archiving tool, one null pointer access causing a segfault and one out of bounds heap read.

At the time I reported the first issues these were already fixed in the main 7-Zip code, but the portable version hadn't been updated yet. Now there is version 16.02, unfortunately there are still issues left.

Null pointer access / segfault
An access to a null pointer in NArchive::N7z::CStreamSwitch::Set can cause p7zip to crash.

Out of bounds read (bug is not publicly visible yet)
An out of bounds heap read access can happen in the function NArchive::N7z::CDecoder::Decode.

Null pointer acctess / segfault (unfixed in 16.02)
A memory allocation isn't checked for a failing allocation. If the file's header indicates a large data size the allocation will fail and subsequently p7zip will try to write to a null pointer. This will likely only lead to a crash and not to further security issues, however this problem seems prevalent in the 7-zip codebase - there are several memory allocations without a check for failures.

p7zip is often used in security appliances to scan inputs, because it supports a large number of archiving file formats. Vulnerabilities in it have played a role in previous attacks on Fireeye appliances. Therefore it's worrying that it's so easy to find crashers in it via fuzzing.

There were also other issues in 7-Zip discovered lately.

Out of bounds read and signed integer overflow in libarchive

I recently wrote about a large number of bugs and potential security issues in libarchive. The release 3.2.0 missed one fix for an out of bounds read in the rar parser. Also I discovered one additional signed integer overflow issue with ubsan. Both issues are now fixed in libarchive 3.2.1.
All issues were discovered with the help of american fuzzy lop.

Out of bounds heap read in RAR parser
Sample rar file

Signed integer overflow in ISO parser
Sample ISO file

Also a couple of other security issues in libarchive were found by Cisco.

With the release of version 3.2.1 I consider libarchive to be reasonably robust against fuzzing. I've tested all supported file formats and fuzzed each one with afl/asan for at least one day. Of course that doesn't mean that no security issues are left - but the easy to find ones should be wiped out.

Many invalid memory access issues in libarchive

libarchive version 3.2.0 (released on April 30th) fixed a large number of memory access bugs that I reported to them a while ago. All issues (except the test suite failure) were found with the help of american fuzzy lop and either address sanitizer or undefined behavior sanitizer.

Unclear invalid memory read in CPIO parser
Sample file

Null pointer access in RAR parser
Sample file

Null pointer access in CAB parser
Sample file

Overlapping memcpy in CAB parser
Sample file

Heap out of bounds read in LHA/LZH parser
Sample file

Stack out of bounds read in ar parser
Sample file

Global out of bounds read in mtree parser
Sample file

Null pointe access in 7z parser
Sample file

Unclear crashes in ZIP parser
Sample file

Heap out of bounds read in TAR parser
Sample file

Unclear invalid memory read in mtree parser
Sample file

Null pointer access in RAR parser
Sample file

Heap out of bounds heap read read when reading password for malformed ZIP
Sample file

Heap out of bounds read in mtree parser
Sample file

I also reported a couple of lower severity issues (leaks, hangs, undefined behavior issues):

Memory leak in TAR parser

Endless loop in ISO parser
Sample file

Undefined behavior / signed integer overflow in mtree parser

Use after free in test suite

Undefined behavior / invalid shiftleft in TAR parser
Sample file

Undefined behavior / signed integer overflow in TAR parser
Sample file

Unfortunately one out of bounds heap read bug in the RAR parser (CVE-2015-8934, sample file) remained unfixed. I hope a fix will find its way into the next version. I was interested in making libarchive more robust because once all issues are fixed it can serve as a safer alternative to many low quality command line tools for various archiving formats.

Various invalid memory accesses in ImageMagick (WPG, DDS, DCM)

Further fuzzing of ImageMagick uncovered some more issues.

An out of bounds memory read in the VerticalFilter() function can be triggered by a malformed DDS file.
Sample file
Git commit / fix
This was fixed in versions 7.0.1-4 and 6.9.4-3.

Several bugs in the WPG parser could lead to a heap overflow and random invalid memory writes. These bugs only seem to appear when a memory limit is set.
Sample for heap write overflow in SetPixelIndex
Sample for unclear invalid write in ScaleCharToQuantum
Sample for unclear invalid write in SetPixelIndex
Git commit / fix 1
Git commit / fix 2
These issues were fixed in versions 7.0.1-4 and 6.9.4-3.

Null pointer accesses and unclear segfaults can happen in the DCM parser.
Sample for null pointer access in ReadDCMImage
Sample for null pointer access in ReadDCMImage (different code)
Sample for unclear segfault in ReadDCMImage
Git commit / fix
These issues were fixed in versions 7.0.1-7 and 6.9.4-5.

ImageMagick heap overflow and out of bounds read

Recently the ImageTragick vulnerability shed some light on the security status of ImageMagick.

This made me wonder how resilient to fuzzing ImageMagick is these days. It's pretty much a posterchild example for a good fuzzing target: Lots of supported complex binary file formats.

I already did some fuzzing on ImageMagick, but as far as I remember that was before I used american fuzzy lop and was done with zzuf. I was also aware that others did some more thorough fuzzing on ImageMagick.

What I did now was relatively simple: I took a trivial, few pixels PNG and used ImageMagick's "convert" tool to convert it into all file formats that have both read and write support in ImageMagick. I used that to run a fuzzing job with afl and asan. By design ImageMagick will sometimes do huge memory allocations, these can be prevented by setting limits for the width, height and memory usage in the policy.xml file.

I discovered one heap buffer overflow in the PICT parser and one heap out of bounds read in the PSD parser. Given how big the attack surface is this is not terrible, but it shows that despite previous efforts there's still potential to fuzz ImageMagick.

Sample file for heap buffer overflow in WritePixelCachePixels() (PICT format)
Git commit / fix

Sample file for heap out of bounds read in PushShortPixel() (PSD format)
Git commit / fix

Both issues have been fixed in the versions 6.9.4-0 and 7.0.1-2. In the meantime new versions (6.9.4-1, 7.0.1-3) came out that, as far as I understand the ChangeLog, remove another potential vector for the ImageTragick vulnerabilities, so you should preferrably update to those.

dosfstools / fsck.vfat: Several invalid memory accesses

I lately fuzzed various filesystem check tools. This uncovered a number of issues in dosfstools / fsck.fat that have now been fixed in the new version 4.0. All issues were found with american fuzzy lop and address sanitizer.

Global out of bounds read file_stat() / check_dir()
Git commit / fix

Unclear invalid memory access in get_fat()
Git commit / fix

Heap overflow in read_fat()
Heap out of bounds read in get_fat()
Git commit / fix for both issues

These bugs can pose a security risk if a system automatically checks attached storage media with fsck or in situations where filesystems on untrusted devices get checked. The new version dosfstools 4.0 fixes all four bugs.

PHP EXIF parser out of bounds reads (CVE-2016-4542, CVE-2016-4543, CVE-2016-4544) and a note on custom memory allocators

PHP recently released the security updates 7.0.6, 5.6.21 and 5.5.35 that fix - among a couple of other security issues - a couple of out of bounds issues in the EXIF parser I reported.

Sample file (CVE-2016-4542)
Sample file (CVE-2016-4543)
Sample file (also CVE-2016-4543)
Sample file (CVE-2016-4544)
Bug report
Git commit

These bugs are not exceptionally interesting, but there is something to know when fuzzing PHP and the same applies also to a number of other applications: It uses a custom memory allocator that can sometimes mask issues from memory safety tools like Address Sanitizer. It is therefore good to know about them and disable them during fuzz testing.

With PHP this can be circumvented by setting the environment variable USE_ZEND_ALLOC=0 while fuzzing. This disables the Zend allocator from PHP and uses normal libc memory allocation calls.

I started documenting such issues and workarounds.

Old OpenSSL bug turns out to be a security issue (CVE-2016-2108)

Today OpenSSL released a security advisory. To my surprise one of the high severity issues involved a bug I had reported about a year ago.

The OpenSSL team didn't consider it to be a security issue - and neither did I. What I did back then was to find all possible inputs of the openssl command line tool and test them with american fuzzy lop, including those that very likely wouldn't have any security impact.

The feature I tested while finding this bug is part of the asn1 parser. It's actually not very well documented, but with openssl asn1parse -genconf [input] you can give OpenSSL a text file in a specific format that will then generate an ASN.1 structure. However it seems highly implausible that in any context one would use such a feature with attacker controlled input - therefore the bugs were fixed, but considered to be not security relevant.

But actually, the bug was not in the parser for that format itself. It was in an ASN.1 encoding function. Therefore applications that take ASN.1 encoded data and reencode it may trigger this code.

The bottom line is probably that we should be careful in claims that certain issues are not security relevant. The good news is that OpenSSL fixed this issue anyway, so all versions since June 2015 are safe.