The curse of vulnerable OpenSSL DLLs
Posted by jpluimers on 2016/12/30
When you ship OpenSSL DLLs, you should provide an update mechanism outside of your regular product cycle that updates these shortly after vulnerabilities are fixed.
Few if any products do that. So I made an overview from products and OpenSSL DLL versions I had installed on various systems.
I’m a developer, so the list is biased towards tools I use often.
All of them are vulnerable: [WayBack] https://www.openssl.org/news/vulnerabilities.html
- 1.0.2.h by ContinuaCI 1.8.1.185 PostgreSQL and Avast 12.3
- 1.0.2.g by SourceTree 1.9.x embedded git_local
- 1.0.2d by Git for Windows 2.6.1
- 1.0.2a by SQLite browser 3.7.0
- 1.0.1m by Delphi 10.0 Seattle
- 1.0.1l by Ruby 2.3
- 1.0.1f by SlikSvn 1.8.5
- 1.0.1g by Delphi XE8, Delphi XE7, VMware Workstation OVF tool and Adobe Creative Cloud 2.8.1
- 1.0.0g by Delphi XE6, Delphi XE5, Delphi XE4, Delphi XE3, Appmethod 1.13 and CollabNet SVN Client 1.7.5
- 1.00d by MarkdownPad 2
- 1.0.0 by FinalBuider 7 XE2 and FinalBuilder 7 EE
- 0.9.8za by VMware Remote Console Plug-in 5.1 and VMware Virtual Infrastructure Client 5.1
- 0.9.8y by VMware VIX Workstation 10
- 0.9.8t by Veaam Backup and Replication
- 0.9.8r by ContinuaCI 1.8.1.185 hg support, VMware VIX and VMware Workstation 8.0.2
- 0.9.8q by Veeam Backup Transport, Veaam Backup, xampp 1.7.4 and Replication and VMware Virtual Infrastructure Client 5.0
- 0.9.8o by xampp 1.7.4
- 0.9.8l by xampp 1.7.4
- 0.9.8n by Delphi XE2, Delphi XE and VMware VIX Workstation 7.1.0
- 0.9.8m by VMware VMRC Plug-in, VMware VIX and VMware Workstation 8.0.2
- 0.9.8i by VMware Virtual Infrastructure Client 4.1
- 0.9.8d by Database Workbench Pro 4.4.3, Database Workbench Pro 5.2.4 and VMware vSphere CLI Perl
- 0.9.8b by Adobe Creative Suite 5
- 0.9.7m by VMware VIX server 1.0.9
- 0.9.7l by VMware VIX VIServer 2
- N/A by Adobe Create Suite 5 and VMware VIX server 1
–jeroen
via: [WayBack] Does Delphi installer install OpenSSL dll’s?
Edwin Yip said
@Jeroen, thanks for the write up. Does the vulnerabilities effect desktop programs (non-server-side software)? Thanks
jpluimers said
I don’t know: I stopped using InterBase a long time ago for various reasons, the most important one the brain drain of the InterBase team.
Joseph Mitzen said
You left out one of my “favorite” examples, Interbase. When the heartbleed bug was revealed, one of Embarcadero’s never-ending supply of managers, Stephen Ball (“Stephen Ball Embarcadero Senior Product Marketing Manager (RAD) & Associate Product Manager (InterBase)”) made a short blog post about it. Fortunately Delphi Feeds has it archived for posterity (and because it’s hard to believe this really happened):
” I am sure many of you have seen in the news this week the well publicised vulnerability in OpenSSL that has been named Heartbleed. https://www.openssl.org/news/secadv_20140407.txt and http://heartbleed.com/ InterBase is not affected by this issue. InterBase encryption uses OpenSSL version 0.9.8g (InterBase 2009), version 1.0.0a (InterBase XE) and version 1.0.0d (InterBase XE3). These editions are NOT affected by this vulnerability….”
Proof: http://www.delphifeeds.com/postings/114672-openssl_and_interbase__all_is_ok
Both myself and Luigi Sandon independently emailed him the same day, explaining that using old versions of OpenSSL was not something to brag about and not a means of security. Worse, we each independently looked up the listed versions and discovered several unpatched security vulnerabilities! Note the irony of titling the post “OpenSSL and Interbase – all is OK”. We both had asked him to remove the mention of the specific versions being used, since they were just advertising to hackers which vulnerabilities to exploit in Interbase.
As is usual for Stephen Ball, he never posted either myself or Luigi’s comments (many Delphi community members will attest that Ball never approves a comment that points out an error or even has a different opinion). He didn’t change the text of the post, either… at least not right away. It appears that some time later he finally did, since the post today omits the versions (with no mention the post was edited).
I don’t care how much it riles Marco Cantu when I say it; I’d gladly trade 10 Embarcadero managers for one employee with an actual background in security… or even just one who does not have “marketing” anywhere in their job description.
jpluimers said
Embarcadero doesn’t give shit about security. Even worse: Embarcadero is clueless about security. They’re clueless about Software Archeology as well.
Too bad the WayBack machine doesn’t have the post archived at archive of community.embarcadero.com/…/openssl-and-interbase-=-all-is-ok-470 so I’ve made it archive this one http://www.delphifeeds.com/…/114672-openssl_and_interbase__all_is_ok
These are the vulnerabilities present in those various InterBase versions:
One of the biggest architectural security problems is that InterBase uses an embedded version of OpenSSL (docwiki.embarcadero.com/InterBase/XE7/en/Requirements_and_Support) which makes it impossible to replace the OpenSSL libraries separately.
A huge documentation issue is that Embarcadero denies a lot of the docwiki for public search because of their pathetic docwiki.embarcadero.com/robots.txt which makes it extremely hard to perform archeology on them (contradicting the Embarcadero papers mentioned in edn.embarcadero.com/bg/article/37560 and community.embarcadero.com/article/technical-articles/149-tools/4684-software-archeology-and-application-factories **)
These are the OpenSSL references I could find:
–jeroen
** the paper links to codegear.com have since long vanished, but I managed to find the actual files, then archived them (they cannot be archived in the WayBack machine, this time because of an even more stupid http://www.codegear.com/robots.txt that is now an HTML file):
PS: Maybe I should make this into a full blog article.
EMB said
Maybe…
Joseph Mitzen said
You did a good – and useful – job tracking down the individual vulnerabilities. The articles about software archeology were very interesting; I hadn’t heard that term before. That is a very restrictive robots.txt file; I’ve suspected the exclusion of bug reports from search engine crawling was for marketing reasons; this is harder to explain.
In regards to a full blog article; there’s really enough material for a series of articles on Embarcadero’s approach to security. :-( For instance, the heap buffer overflow vulnerability from 2014 is a very telling example. I managed to track down the timeline compiled by the company that found the bug and it is like a comedy skit. In fact, I’ve toyed with creating a blog myself for some time just to analyze all that went wrong after this vulnerability was reported.
https://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-buffer-overflow
The highlights here include taking almost two months – and the involvement of a government agency under the United States Department Of Homeland Security! – to get Embarcadero to even respond to the reporting company’s report. Other companies I deal with have dedicated security email lists complete with a GPG key and address for passing along logs that can’t be anonymized or information too sensitive to post directly to the list. Of course, the second head-scratcher was, after finally acknowledging the vulnerability report, the geniuses simply added it to the bug tracker, complete with proof of concept code to exploit the bug! Sigh. Then they dragged their feet for weeks and kept saying this was because of the extensive testing they were doing. When they finally deliver the fix, the security company is able to tell them the same day that it doesn’t work! They turn down any help giving Delphi developers early warning about the vulnerability and, despite sending an endless stream of marketing emails, have no system in place to notify customers early about security vulnerabilities. They don’t even bother providing anything so simple as a diff file for anyone using a version older than the most recent. :-(
Eventually I learned that this wasn’t even the end of the problem! Another way to exploit the problem was discovered, leading to more craziness….
https://www.coresecurity.com/advisories/delphi-and-c-builder-vcl-library-heap-buffer-overflow
Once again Embarcadero drags their feet, suggesting they’re not devoting much resources to solve the problem.
In fact, I discovered when replying to you that the story doesn’t even end here! Core Securities apparently produced their own utility to patch existing executables affected by the bug (which is more than what Embarcadero bothered to do).
https://www.coresecurity.com/blog/for-skype-and-other-affected-applications-a-workaround-for-embarcadero-vcl-library-heap-overflow
Core Security rightly points out that this bug leaves an untold number of old, vulnerable programs out there that would need to be recompiled; their solution is arguably more useful. They also took a swipe at Embarcadero’s code quality:
“The problem here is that the fix was badly implemented, and the checking was introduced in a wrong place. This was a partial fix – it eliminated one path to exploitation – but it did not address the source of the problem.”
Sigh.
If anyone from Embarcadero ever tries to defend their security skills, I believe recounting this saga with Core Technologies would put them in their place.
It’s not the only time Delphi has garnered publicity for a security bug either. Way back with Delphi 4, the Randomize function was using the number of milliseconds since midnight to seed the generator. This caused two problems: the number of possible seeds was much smaller than the precision of the seed, and the seed was predictable. This was exploited against an online poker game written in Delphi by setting one’s system clock to the same time as the server’s, thus allowing the seed, and hence all subsequent random numbers, to be predicted.
http://www.ibm.com/developerworks/library/s-playing/
“The flaw exists in the card shuffling algorithm used to generate each deck. Ironically, the code was publicly displayed at http://www.planetpoker.com/ppfaq.htm with the idea of showing how fair the game is to interested players (the relevant question has since been removed). In the code, a call to randomize() is included to produce a random deck before each deck is generated. The implementation, built with Delphi 4 (a Pascal IDE), seeds the random number generator with the number of milliseconds since midnight according to the system clock. That means the output of the random number generator is easily predicted. A predictable “random number generator” is a very serious security problem.
By synchronizing our clock with the clock on the online casino and hitting the “shuffle” button, our program can calculate the exact shuffle. That means we know all the cards that have yet to appear, everyone’s hand, and who will win. The screen shot below shows the information displayed by our program in realtime during an actual game. Our program knows what cards are to appear in advance, before they are revealed by the online game.”
I believe the current Randomize function is based on the uptime on the system, which can also often be determined (or even offered by the server in login messages!). The actual random number generator itself also isn’t very impressive:
https://www.delphitools.info/2011/12/13/pimp-your-random-numbers-with-xorshift/
I had a false memory of Borland fixing the problem, but David Heffernan corrected me on this. All they’ve done for 17 years is add this notice to the Random function documentation:
“Note: Because the implementation of the Random function may change between compiler versions, we do not recommend using Random for encryption or other purposes that require reproducible sequences of pseudo-random numbers. ”
http://docwiki.embarcadero.com/Libraries/Berlin/en/System.Random
Of course, the reason you shouldn’t depend on it for encryption has nothing to do with the algorithm potentially changing; it has to do with the weak source of entropy and the similarly weak pseudorandom number generator. This is all the more baffling in an era in which the major OSes all offer superior sources of entropy. For instance, Python offers an additional random function suitable for cryptographic use:
“This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation.
On Linux, getrandom() syscall is used if available and the urandom entropy pool is initialized …. On a Unix-like system this will query /dev/urandom. On Windows, it will use CryptGenRandom(). If a randomness source is not found, NotImplementedError will be raised.”
In addition, the pseudorandom number generator uses the Mersenne Twister, “one of the most extensively tested random number generators in existence” (as does FreePascal). Unlike Delphi’s Random documentation, the Python version ends with:
“Most of the random module’s algorithms and seeding functions are subject to change across Python versions, but two aspects are guaranteed not to change:
If a new seeding method is added, then a backward compatible seeder will be offered.
The generator’s random() method will continue to produce the same sequence when the compatible seeder is given the same seed.”
It’s almost like it never occurred to Embarcadero that they could do this. :-(
jpluimers said
Thanks. Be sure to mention this on G+.
Here are archived versions of the URLs you mentioned: