Full disclosure: libsrtp multiple vulnerabilities

I wrote a fuzzer for libsrtp for purely recreational reasons. I reported the bugs I found to the libsrtp security mailing list several months ago. Finally those bugs seem to have been fixed in the git master tree. Apparently these findings and fixes for them don’t seem to prompt a new release. Cisco has stopped responding and I don’t know what the deal is. I recently also contacted Cisco Talos but they didn’t respond at all. So I’ve decided to publish my fuzzers. I put considerable effort in it but I’m now tired of this project because nobody really seems to care, and I am abandoning it.  Underwhelming experience, exception to the rule.

EDIT 23/03: Removed invalid information about Talos. My bad.

Security audit of SoftEther VPN finds 11 security vulnerabilities

A security audit of the widely used SoftEther VPN open source VPN
client and server software [1] has uncovered 11 remote security
vulnerabilities. The audit has been commissioned by the Max Planck
Institute for Molecular Genetics [2] and performed by Guido Vranken
[3]. The issues found range from denial-of-service resulting from
memory leaks to memory corruption.

The 80 hour security audit has relied extensively on the use of
fuzzers [4], an approach that has proven its worth earlier with the
discovery of several remote vulnerabilities in OpenVPN in June of 2017
[5]. The modifications made to the SoftEther VPN source code to make
it suitable for fuzzing and original code written for this project are
open source [6]. The work will be made available to Google’s OSS-Fuzz
initiative [7] for continued protection of SoftEther VPN against
security vulnerabilities. An updated version of SoftEther VPN that
resolves all discovered security vulnerabilities is available for
download immediately [8].

[1] https://www.softether.org/
[2] https://www.molgen.mpg.de/2168/en
[3] https://guidovranken.wordpress.com/
[4] https://en.wikipedia.org/wiki/Fuzzing
[5] https://guidovranken.wordpress.com/2017/06/21/the-openvpn-post-audit-bug-bonanza/
[6] https://github.com/guidovranken/SoftEtherVpn-Fuzz-Audit
[7] https://github.com/google/oss-fuzz/blob/master/README.md
[8] http://www.softether.org/5-download/history

Thank you very much OSTIF

In May I started building fuzzers for OpenVPN because I liked engaging in the challenge of finding more vulnerabilities after two fresh audits. I never intended or expected to receive money for this. In addition to the money donated by people and companies to my Bitcoin address (thank you very much again), OSTIF reached out to me and offered to reward me with a bounty of $5000 for the vulnerabilities and for completing the fuzzers. Thank you so much!

The fuzzers can be found here: https://github.com/guidovranken/openvpn/tree/fuzzing There are still some small portions of code that remain un-fuzzed. I am very busy with contracting work so I won’t be working on it sometime soon. You are welcome to extend it and find more vulnerabilities, and you might be eligible for bounties yourself.

OSTIF is currently running a fundraiser to get OpenSSL 1.1.1 audited. Check it out and spread the word.

One more OpenVPN vulnerability (CVE-2017-12166)

This concerns a remote buffer overflow vulnerability in OpenVPN. It has been fixed in OpenVPN 2.4.4 and 2.3.18. It is suspected that only a small number of users is vulnerable to this issue, because it requires having explicitly enabled the outdated ‘key method 1’.

The advisory can be found here: https://community.openvpn.net/openvpn/wiki/CVE-2017-12166

If you appreciate my discovery, you may donate some BTC to address 1BnLyXN2QwdMZLZTNqKqY48bU4hN2A3MwZ

In ssl.c, key_method_1_read() calls read_key() which doesn’t perform adequate
bounds checks. cipher_length and hmac_length are specified by the
peer:

1643 uint8_t cipher_length;
1644 uint8_t hmac_length;
1645
1646 CLEAR(*key);
1647 if (!buf_read(buf, &cipher_length, 1))
1648 {
1649 goto read_err;
1650 }
1651 if (!buf_read(buf, &hmac_length, 1))
1652 {
1653 goto read_err;
1654 }

And this many bytes of data are then read into key->cipher and key->hmac:

1656 if (!buf_read(buf, key->cipher, cipher_length))
1657 {
1658 goto read_err;
1659 }
1660 if (!buf_read(buf, key->hmac, hmac_length))
1661 {
1662 goto read_err;
1663 }

In other words, it’s a classic example of lack of a bounds check resulting in a buffer overflow.

Bitcoin fuzzers

I got some requests to fuzz Bitcoin, so I did. They can be found here:

https://github.com/guidovranken/bitcoin/tree/fuzzing/fuzzers

I expect them to be merged into the main project soon.

So far only one issue has been found: https://github.com/bitcoin/bitcoin/pull/11081 . This code is currently unused and does not pose a security risk (forks of Bitcoin may want to check whether they are using it).

Judging by the number of issues found (1) after extensive fuzzing, the Bitcoin code appears to be exceptionally well-written. Which is also exceptionally good news, because this code is not only used by Bitcoin but also by many, many altcoins, and thus guards billions and billions of dollars.

I’m actively working on expanding the fuzzers and their code coverage (as much as time permits).

Tip jar: 1BnLyXN2QwdMZLZTNqKqY48bU4hN2A3MwZ

In other news, I have a new OpenVPN vulnerability coming up that’s the worst yet in terms of severity but only affects a small number of users. To be announced.

bc

11 remote vulnerabilities (inc. 2x RCE) in FreeRADIUS packet parsers

FreeRADIUS is the most widely deployed RADIUS server in the world. It is the basis for multiple commercial offerings. It supplies the AAA needs of many Fortune-500 companies and Tier 1 ISPs.” (http://freeradius.org)

FreeRADIUS asked me to fuzz their DHCP and RADIUS packet parsers in version 3.0.x (stable branch) and version 2.2.x (EOL, but receives security updates). 11 distinct issues that can be triggered remotely were found.

The following is excerpted from freeradius.org/security/fuzzer-2017.html which I advise you to consult for more detailed descriptions of the issues at hand.

There are about as many issues disclosed in this page as in the previous ten years combined.

v2, v3: CVE-2017-10978. No remote code execution is possible. A denial of service is possible.
v2: CVE-2017-10979. Remote code execution is possible. A denial of service is possible.
v2: CVE-2017-10980. No remote code execution is possible. A denial of service is possible.
v2: CVE-2017-10981. No remote code execution is possible. A denial of service is possible.
v2: CVE-2017-10982. No remote code execution is possible. A denial of service is possible.
v2, v3: CVE-2017-10983. No remote code execution is possible. A denial of service is possible.
v3: CVE-2017-10984. Remote code execution is possible. A denial of service is possible.
v3: CVE-2017-10985. No remote code execution is possible. A denial of service is possible.
v3: CVE-2017-10986. No remote code execution is possible. A denial of service is possible.
v3: CVE-2017-10987. No remote code execution is possible. A denial of service is possible.
v3: CVE-2017-10988. No remote code execution is possible. No denial of service is possible. Exploitation does not cross a privilege boundary in a correct and realistic product deployment.

Contact me if

  • you are a vendor of a (open source) C/C++ application and want to eliminate security issues in your product
  • you or your company relies on an (open source) C/C++ application and want ensure that it is secure to use
  • you’d like to organize a crowdfunding campaign to eliminate security issues in an open source C/C++ application for the benefit of all who rely on it
  • for any other reason

I almost always find security issues.

guidovranken at gmail com