Community
Participate
Working Groups
Dear Eclipse Security Team, We are a team of security researchers and recently looked at Scandium, the DTLS library of Californium. During our analysis, we found multiple problems within the library. The bugs are present both in the master’s branch (which is associated with version 1.0.x) and in the 2.0.x branch. State Machine Issues: We discovered that both the Scandium DTLS client and server can complete a handshake without having received a ChangeCipherSpec message from the other peer. The lack of the ChangeCipherSpec message causes the communication peer to accept unencrypted application data at epoch 0. This is comparable to CVE-2014-6593 which is described in detail in[https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-de-ruiter.pdf]. The vulnerability is fortunately not fatal for Scandium, as an attacker still needs to forge a valid finished message. We did not find a way to do this with Scandium. However, attack scenarios with rouge libraries or the like are imaginable. The core of the problem is that Scandium does not explicitly implement a State Machine which enforces that only reasonable messages are processed. As it is, it oftentimes appears to be sheer luck that an attacker cannot do more harm. For example, if a client sends two different client key exchange messages this only gets noticed by Scandium because it tries to overwrite an already set master secret. In other places, the code just crashes with NullPointerExceptions and the like. We highly recommend that you enforce that only “expected” messages get processed. CBC-Issues We also took a brief look at the Scandium CBC decryption routine. The way CBC decryption is implemented in Scandium, various attacks that are known from the TLS research community are possible. The Implementation is vulnerable to a (D)TLS variant of Poodle (https://www.openssl.org/~bodo/ssl-poodle.pdf). This is because Scandium does not check all padding bytes of a received record but only looks at the last byte of the padding and skips over the rest. This results in a behavior that is comparable to SSLv3. An attacker can send manipulated CBC records to a Scandium server and use it as an oracle to decrypt the last byte of each ciphertext block. Depending on the application which uses Scandium it might even be possible to decrypt more than that (if an attacker can shift the unknown plaintext in a cipher block). To prevent this attack Scandium has to check every byte of the padding for its correctness. Additionally, the Scandium CBC implementation is not implemented in constant time. It is therefore vulnerable to Timing Based CBC Attacks like classic Vaudenay Padding Oracle Attacks or Lucky13. This is not as severe in DTLS as it is in TLS (due to no trivial backchannel it is harder to attack), however, this is still exploitable (as shown in https://www.ndss-symposium.org/wp-content/uploads/2017/09/01_1.pdf). Since in DTLS a connection is not closed upon the reception of a record with an invalid mac, an attacker can interleave valid and invalid records and use the timing information retrieved from the processing of the flight as a timing side-channel for the invalid record. Other side channels are also possible (like Heartbeat or connection timeouts). The only real countermeasure to these attacks is to do the whole CBC decryption in constant time or to deactivate CBC all together. Note that there are a lot of pitfalls in a correct secure implementation (see https://tools.ietf.org/html/rfc5246#section-6.2.3.2 for hints). If you need further assistance with these issues or further clarification, feel free to contact us. Cheers Robert Merget, Paul Fiterau Brostean, Juraj Somorovsky
I've added the project leads and the most active committer in CC. Project team, the handbook has some help regarding the security policy and the means by which we report vulnerabilities. https://www.eclipse.org/projects/handbook/#vulnerability
Dear Robert, thanks a lot for taking the time to test Scandium with such level of scrutiny. We take security very seriously and will start our evaluation of the issues brought up by you and your team soon. We will get in touch via this channel in case of further questions. Thanks again for taking the time and reporting your findings. We appreciate it. Kai
Also from my side, thank you very much for your efforts! About the CCS: Though the master secret is required for a FINISH, my feeling is, that fixing this is not that urgent. I hope I can manage to fix it before the 2.0.0 release. About CBC: Generally we marked CBC as "should be avoid" https://github.com/eclipse/californium/blob/master/scandium-core/src/main/java/org/eclipse/californium/scandium/dtls/cipher/CipherSuite.java#L75 Though other cipher suite without CBC are supported, everyone can at least exclude it. About CBC padding-check: Checking the padding seems to be easy. I will prepare a PR for master (previous 2.0.x) and the 1.0.x. About other CBC attack and countermeasures: Timing oracles for a "clustered, multi node, multi processor, multi thread java" implementations seems to me to be very unrealistic. "implemented in constant time": I'm not sure, if this reflects some points in the implementation. If so, please guide me to that points! If this is based on observations/experiments, that would be the expected behaviour using java multi thread on a multi processor. At least expected from my side.
In regards to the State Machine Flaw: Yes, as far as we can tell additional flaws would be required to realistically exploit this. In Regards to CBC in general: Note that this is not a "general" problem of CBC cipher suites but an implementation flaw. A user of the library would not know if you have implemented the cipher suite side-channel-free or not. CBC in TLS is just very very hard to implement securely, we, therefore, recommend not supporting it at all, or at least deactivate them by default. In regards to the CBC-Timing: I did not measure your implementation. This has not directly something to do with "clustered, multi node, multi processor, multi thread java". Everything the processor does besides performing the decryption just adds random noise to the signal an attacker wants to measure. Since that noise does not depend on the secret he wants to decrypt at all, the noise can be filtered by the attacker with statistical methods. Past research, for example by Kenneth Patterson or Sebastian Schinzel, has shown that this is practically exploitable. From my own experience, especially Lucky13 timing-based side channels are very measurable by an attacker in a local area network environment, even without special hardware-based timing measurement equipment (something like this: https://exablaze.com/exanic-hpt). Currently, the code uses various branches based on secret values. For example in the DatagramReader.java which is used by the decryptBlockCipher() to find the HMAC. Or more subtle (but with greater impact) in the HMAC computation, which causes the implementation to be vulnerable to the Lucky13 attack (http://www.isg.rhul.ac.uk/tls/TLStiming.pdf). Depending on the padding, the computation of the HMAC might need additional hash computations which drastically increases the processing time of the record. Note that his vulnerability attacks the TLS/DTLS specification, and requires additional countermeasures from the implementation to be mitigated. The paper (page 16-17) describes how to implement them. This effect is even amplified in DTLS, since an attacker can chain invalid records like this: "invalid Record, invalid Record, ...,invalid Record, invalid Record, invalid Record, valid Record " ,and then compute the average computation time for the processing of an invalid record without redoing the whole handshake. It is not trivial to implement CBC side-channel free, even if you try. Numerous vulnerabilities have shown this in the past: OpenSSL, CVE-2016-2107, Botan 1.11.21, CVE-2015-7824 OpenSSL, CVE-2019-1559 Citrix, CVE-2019-6485 F5, CVE-2019-6593, SonicWall SonicOs, CVE-2019-7477 ... ... As already mentioned, we recommend not supporting CBC.
> we, therefore, recommend not supporting it at all, or at least deactivate them by default. OK, when Simon is back, we can discuss https://github.com/eclipse/californium/issues/909 again, and potentially got for https://github.com/eclipse/californium/issues/909#issuecomment-473171902 (defaults without CBC). ############################################### > As already mentioned, we recommend not supporting CBC. AFAIK LwM2M 1.0 requires it. Though that is one of the major use-cases, "not supporting CBC" may be too hard. ############################################### I personally still have my doubts about such attacks. Is there any test-software available for "free" (may be as "open source")? Do you have a guess, how much time it requires to get used to such a software and check such attacks?
Yes, I may have forgotten to mention, our team develops TLS-Attacker (https://github.com/RUB-NDS/TLS-Attacker) which recently got prototype DTLS support. You could use this framework to develop such attacks fairly simple or to develop scanners for DTLS. Although we do not have anything implemented yet. We just started working on DTLS so we do not have good automatic DTLS-Scanners yet. The timing based attacks are hard to scan, since they usually require that the attacker is somewhat close to the target (which is imho plausible since the attacker is a man-in-the-middle anywas). The Poodle-Style vulnerability is scannable remotly.
> This has not directly something to do with "clustered, multi node, multi processor, multi thread java". According http://www.isg.rhul.ac.uk/tls/TLStiming.pdf, end of page 6, "In DTLS, there are no error messages, but the techniques of [1] can be applied to solve this problem. There, the authors send a packet containing a ciphertext C closely followed by a DTLS message, with the latter always provoking a response message." With the multi thread DTLS implementation of scandium, the "sequence of records" will be converted in a parallel processing of the records. Therefore the response time for the later will hardly depend on the processing time of the first. With that, FMPOV, fixing the program failures around the padding and, if agreed by others, the reintroduction of the "default cipher suite" should do it.
@Robert, @Paul and @Juraj, Thank you very much for this feedback we really appreciate this ! I think, we really need this kind of expertise for Scandium ! The LWM2M specification say : > Implementing authenticated decryption (checking padding and mac) > without any side channel is hard (see Lucky 13 attack and its variants). > The solution is to use the encrypt-then-mac > extension defined in RFC 7366, which is recommended. So, I would like to know if you agree that using the rfc7366[1] would fix the timing attack exposure ? [1]https://tools.ietf.org/html/rfc7366 @Achim, only activate TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 TLS_PSK_WITH_AES_128_CCM_8 ciphers by default make sense to me (as this is default CoAP ones) We can also add a warn when CBC ciphers are used.
(In reply to Simon Bernard from comment #8) > @Robert, @Paul and @Juraj, > Thank you very much for this feedback we really appreciate this ! > I think, we really need this kind of expertise for Scandium ! > > The LWM2M specification say : > > Implementing authenticated decryption (checking padding and mac) > > without any side channel is hard (see Lucky 13 attack and its variants). > > The solution is to use the encrypt-then-mac > > extension defined in RFC 7366, which is recommended. > > So, I would like to know if you agree that using the rfc7366[1] would fix > the timing attack exposure ? > > [1]https://tools.ietf.org/html/rfc7366 > > @Achim, > only activate TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 TLS_PSK_WITH_AES_128_CCM_8 > ciphers by default make sense to me (as this is default CoAP ones) > We can also add a warn when CBC ciphers are used. Disabling the CBC ciphers by default sounds reasonable to me too.
> So, I would like to know if you agree that using the rfc7366[1] would fix the timing attack exposure ? Yes, if the Encrypt-then-Mac extension is negotiated and implemented correctly the timing issues are fixed. You just have to make sure that you check the MAC before you decrypt the message. Towards the multi-threaded / cluster discussion: It does not matter for the attack that the implementation processes records in parallel. An attacker can simply send the same invalid record 10000 times and then forward a valid record for which he expects a response. Lets say you have a 16 core machine 16 records get processed at the same time. Lets say the processing of a record with valid padding takes 0.2ms and the processing of a record with invalid padding takes 0.19ms. For a 16 core machine to process 10k records with invalid padding it will take 10000/16 * 0.2ms = 125 ms while for 10k records with valid padding it will take 118.75ms. So if the attacker received a response after ~12.5 ms he will assume its valid padding, if he received it faster he will assume it was invalid. In a real attack the attacker does this for 256 different modifications, so he will just assume that the slowest response was a valid padding. If this timing difference is too small for the attacker he can just continue sending the same records again and again to increase the difference he has to measure. A real world attacker can use clever statistics to reduce the amounts of guessing. Any noise that is created by the operating system or other software affects all the measurements of the attacker equally. As long as there is ANY timing difference a sophisticated attacker can decrypt it: https://eprint.iacr.org/2015/1129 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.700.1952&rep=rep1&type=pdf https://eprint.iacr.org/2018/747 I can totally understand that you may not want to invest the engineering power in a constant time CBC implementation since the attack is non-trivial, but you should then imho at least document that the implementation is not secure against such attacks.
Today we released the 2.0.0-M17 milestone. It comes with: - Handshake state machine - CBC cipher suite are only available, if explicitly unlocked - improved decoding of handshake messages FMPOV, that should fix the reported vulnerabilities.
If the project team feels that a CVE is warranted, instructions are in the handbook. https://www.eclipse.org/projects/handbook/#vulnerability-cve
@Robert Merget I tried to use the TLS-Attacker to check the improvements of 2.0.0-M17. Therefore I started the cf-secure SecureServer with NO_AUTH java -jar cf-secure-2.0.0-M17.jar NO_AUTH (see https://github.com/RUB-NDS/TLS-Attacker/issues/63). For me the TLS-Attacker seems to be more starting to support DTLS, some DTLS specific details seems to be missing. e.g. the padding oracle attack java -jar Attacks.jar padding_oracle -cipher TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 -version DTLS12 -connect localhost:5684 reports: #################################################### 13:42:40 [pool-2-thread-1] ERROR: TlsTask - Could not execute Workflow. de.rub.nds.tlsattacker.attacks.exception.FingerprintExtractionException: Could not extract fingerprint. Not all actions executed as planned at de.rub.nds.tlsattacker.attacks.task.FingerPrintTask.execute(FingerPrintTask.java:47) at de.rub.nds.tlsattacker.core.workflow.task.TlsTask.call(TlsTask.java:53) at de.rub.nds.tlsattacker.core.workflow.task.TlsTask.call(TlsTask.java:16) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 13:42:45 [pool-2-thread-1] WARN : TlsTask - Encountered an exception during the execution de.rub.nds.tlsattacker.attacks.exception.FingerprintExtractionException: Could not extract fingerprint. Not all actions executed as planned at de.rub.nds.tlsattacker.attacks.task.FingerPrintTask.execute(FingerPrintTask.java:47) at de.rub.nds.tlsattacker.core.workflow.task.TlsTask.call(TlsTask.java:53) at de.rub.nds.tlsattacker.core.workflow.task.TlsTask.call(TlsTask.java:16) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) #################################################### For DTLS 1.2 it may be considered, that no alert is send at all, so the warning and error may just be skipped Therefore: Is there a plan to improve the DTLS1.2 functionality in TLS-Attacker in the near future? Or is the priority of the DTLS 1.2 support rather low? If you have interest, I would create DTLS 1.2 specific issues on github.
FMPOV we do not need a CVE as there was no real exploit being demonstrated, or am I mistaken?
(In reply to Kai Hudalla from comment #14) > FMPOV we do not need a CVE as there was no real exploit being demonstrated, > or am I mistaken? Your call. If you're not certain, connect with your PMC or security@eclipse.org for advice/assistance.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/438.
