Security vulnerability + preferred disclosure channel

[obi1kenobi]

I discovered a serious security vulnerability in the database, and in the spirit of responsible disclosure, I was hoping to discuss it privately with the maintainers of this project. However, I was not able to find a contact email address of any kind for OrientDB or its parent company. I would appreciate it if one of the maintainers could reply to this issue and direct me to the preferred channel for disclosing security vulnerabilities.

[lvca]

@obi1kenobi Thanks for contacting us about this. Could you please write to support -at- orientdb.com?

[obi1kenobi]

Reached out to the email address you specified. Thank you for the prompt reply!

Would it make sense for you to update the docs or main site with this info on how to handle security disclosures, so they go smoother in the future?

[lvca]

Good idea, I'm going to create a chapter for it.

[micha-heigl]

What is the status on this? It would be very helpful to have some info

• how serious is the vulnerability?
• what areas are impacted?
• is there a workaround to have a quick fix in a running system?
• when will there be a patch available?

[smolinari]

@micha-nerdlichter

I think this is probably the solution.

#5611

Scott

[obi1kenobi]

Now that the issues have been fixed in the develop branch, here are the issues I reported and their fixes. Hoping to get these backported to all active releases and have patches available as soon as possible.

Random passwords generated with weak entropy

• Severity: high
• Remotely exploitable: yes
• Fixed in develop: link
• Workaround: do not use auto-generated random passwords

Consider line 681 in OServer.java that is responsible for auto-generating passwords. Note that it uses the variable random which on line 104 of the same file is instantiated as new Random(). This means that it uses Java's default Mersenne Twister random-number generator initialized with the current system time as a seed, which is not secure because it is easily predictable.

Fixed by switching to the SecureRandom random-number generator.

Random passwords generated with insufficient entropy

• Severity: medium
• Remotely exploitable: yes
• Fixed in develop: link
• Workaround: do not use auto-generated random passwords

Once again, consider line 681 in OServer.java that is responsible for auto-generating passwords. The password is generated from 64 bits of randomness from a RNG. 64 bits is not enough entropy to deter a sophisticated and determined attacker -- for example, the peak hashing rate of Bitcoin last month (December 2015) was over 900,000,000,000,000,000 ~= 2^59.7 hashes per second, exhausting a hash space of 64 bits in under 20 seconds.

Fixed by increasing the amount of entropy to 256 bits.

Password hashing with outdated algorithm

• Severity: medium
• Remotely exploitable: no, need a copy of the table of password hashes
• Fixed in develop: link 1 link 2
• Workaround: none, ensure you are using a very strong password as a mitigation measure

Currently, OrientDB hashes passwords with SHA-256, which is not secure. Based on issue #1229 it seemed like in version 2.2 the default was going to be PBKDF2-HMAC-SHA1 instead. However, SHA-1 is a broken hashing algorithm and should not be used any more.

Fixed by implementing PBKDF2-HMAC-SHA256 password hashing and making it the default algorithm.

Comparison of plaintext passwords vulnerable to timing attack

• Severity: high
• Remotely exploitable: yes
• Fixed in develop: link
• Workaround: place your database behind a VPN / firewall so that it's not accessible via the public Internet

When connecting to the server via the binary protocol, ONetworkProtocolBinary.connect() passes the received username and password to OServer.serverLogin(), which in turn calls OServer.authenticate() with the plaintext password. Line 540 in that function uses a regular string comparison to check the user's password against the provided one, which means that it will short-circuit and return False as soon as the first mismatched character is discovered. This operation can be timed, as this link explains, to retrieve the user's password.

Fixed in develop by hashing both passwords and comparing their hashes using a constant-time comparison.

Comparison of digests vulnerable to timing attack

• Severity: low
• Remotely exploitable: yes but requires tremendous expenditure of resources
• Fixed in develop: no, the offending code has been removed from develop
• Workaround: place your database behind a VPN / firewall so that it's not accessible via the public Internet

Similarly to the above, line 93 in OSecurityManager.check() does a string comparison of digests, which also short-circuits and is vulnerable to timing. That check() function seems to be used for record-level security features, so this is also a significant concern and should be fixed even though it would be significantly more difficult to exploit than the one above.

No fix made in develop, the offending code has been removed.

[obi1kenobi]

Also, I want to thank @lvca and the other members of the OrientDB team for promptly reacting to these issues and fixing them so quickly. I've reported lots of issues in the past, and I have to say that this time around the process went as smoothly as it's ever gone.

[micha-heigl]

Thank you @smolinari for the hint and thank you @obi1kenobi for all the fixes and the details.

@lvca it would be very helpful to have a security label on such issues.

[lvca]

@micha-nerdlichter good idea, done.

[obi1kenobi]

The timing attack vulnerabilities were not fixed in 2.1.10, which is extremely concerning given that the plaintext password timing attack is trivially exploitable even over a network. Read this paper on a similar timing attack executed over a wide-area network if you don't believe me:
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Please strongly consider backporting the fixes from develop into the 2.1.x series and release a new version.

[lvca]

@obi1kenobi Please could you open a PR against 2.1.x? #5611 (comment). We'll merge it at record time.

[tglman]

hi guys, notice before port everything to 2.1 that 'PBKDF2WithHmacSHA256' is not present in java7 by default, we need to be compatible with that.

[lvca]

@tglman you're right.