If there are any doubts about the security of a particular algorithm, why not go the extra mile and disable it altogether? These changes should be balanced with compatibility concerns. Those tools are not perfect and cannot detect the presence of such mitigations. A vulnerability scanner does not know such information it checks for the presence of the specific packages versions, matches them with known impacted versions and reports the finding. That article also clarifies that the mitigation in question was applying upstream patches, further lowering the probability of successfully conducting the attack. Red Hat also provided a workaround to disable CBC ciphers from sshd configuration. In fact, the aforementioned NIST page for CVE-2008-5161 has Red Hat vendor statement displayed prominently, stating that the issue is fixed from RHEL 5. Thankfully Red Hat is working proactively to monitor and mitigate the vulnerabilities present in its products. Sentences like, “It is therefore very unlikely for an interactive session to be usefully attacked using this protocol weakness: an attacker would expect around 11356 connection-killing attempts before they are likely to succeed“ might be soothing, but does that mean that this decade-old security issue wasn’t addressed in RHEL? Maybe another reference was made to this or some other equally cryptic document. ![]() It is highly likely that this investigation started from an automated vulnerability scanner alert noticing that the OpenSSH server is willing to use CBC cipher modes, citing CVE-2008-5161 as the reason. Diffie–Hellman key exchange is also from 1976, yet it is still widely used and isn't considered insecure.Īll that information does not really help in understanding what the situation is about then. However, being old doesn't automatically mean insecure. It also says that it was invented in 1976, which could indicate it’s out of date and insecure. It also names it “the most commonly used mode of operation” and “one of two block cipher modes recommended by Niels Ferguson and Bruce Schneier.” It says that CBC is one of the many modes of using a block cipher, the one XORing the current ciphertext block with the previous one before encrypting it. Let’s step back a bit and analyse the problem at hand, with the help of this Wikipedia entry. These questions, thankfully, can be answered with technologies available in RHEL 8 to enhance operational efficiency and improve confidence and understanding of crypto-policy tools. What tools are you going to use? What checks are you going to make? Have you configured the system properly? Are your servers free of known vulnerabilities? In this post, we’ll walk through an example of how to configure Red Hat Enterprise Linux (RHEL) 8 crypto-policy to remove Cipher block chaining (CBC), but let’s start with a little background on CBC and default crypto-policy on RHEL 8.Īt an operational level, most of us have experienced situations where there is a complex configuration on a system, and there is either too much or too little information to understand everything.įor example, have you ever run into a statement like, “Your server supports CBC ciphers which are no longer recommended and vulnerable,” and then asked whether you are protected from a new vulnerability, along with a request to report ASAP and remediate if some systems across your estate are impacted?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |