This weekly report is to discuss some of the more interesting vulnerabilities that have been found and to make sure that you patch appropriately. If there is not a patch available make sure to check for signatures or patterns that you can use to build content for your compensating security controls.
1. OpenSSL Multiple Vulnerabilities
Multiple vulnerabilities were patched today for the OpenSSL library. The majority of these were for DTLS packets and implementations. For more information on these vulnerabilities please check the Technical Details section.
It would be best to update the OpenSSL packages as soon as possible. These are currently not available upstream by most flavors, so it might be best to manually apply the patch until the patches are upstream.
SRP/DTLS EC(DH) Ciphersuite Null Pointer Dereference
If a client had attempted to negotiate a handshake using the SRP or anonymous DTLS EC(DH) cipher suite and the server did not allow those ciphers, then the client would crash with a null pointer dereference based on the server response. A server with a maliciously crafted response could respond with a mask of disabled ciphers that included SRP or anonymous DTLS EC(DH). The client, previous to the patch, did not support this and c->mask_* would point to 0.
Heap Write Overrun Race Condition
“If a multi threaded client connects to a malicious server using a resumed session and the server sends an ec point format extension it could write up to 255 bytes to freed memory.”
This means that both the client and server would end up being controlled here in order to take advantage of the vulnerability. Generally this would be a write OOB as the pointer value to the written location is not reused to make it a use after free type condition. The write could be controllable in other situations, but the requirement for exploitability is too high.
DTLS Double Free
A DTLS packet may be in a buffered state while either dtls1_reassemble_fragment or dtls1_process_out_of_seq_message errors gets hit. Once either of these functions trigger an error it attempts to free the item value that could still be held in buffered messages. Once this was freed and buffered messages ends by destruction of ssl*, a double free happens.
DTLS Handshake Memory Exhaustion
The DTLS maximum message size was controlled by a user controlled certificate length + max encrypted length. As long as this value was under the allowed size, the maximum message size amount of bytes for msg_len could be allocated. This could be a value of upwards of 16MB + 2MB (reassembly bitmap) for just a pending handshake. Up to ten handshakes could be established per DTLS connection using upwards of 180MB of memory. More DTLS connections could be made to continuously increase this memory consumption.
DTLS Zero-Length Fragment Memory leak
If an attacker attempts to use a duplicate sequence number of an established fragmented session and has a fragment length of 0, it would skip an important reassembly step and instead allocate memory for a new fragment. This would leak the fragment and continuos attempts at this would exhaust the memory.
TLS Version Downgrade
An attacker who controls a man in the middle situation of a vulnerable client may create very small fragments for a ClientHello and older OpenSSL versions would assume TLS 1.0 to avoid downgrade attacks. This was because SSL 3.0 clients did not utilize such fragments, so TLS 1.0 was a good bet a while ago, ironically leading to the new downgrade attack.
SRP Buffer Overrun
An SRP client or server can send certain parameters that lead up to a buffer overrun situation. These values are in the client key when calculating values in srp_Calc_k() or srp_Calc_u() for g and N values.
Information leak in pretty printing functions
2. Cacti SQLi and RCE
Multiple vulnerabilities were found in Cacti and a patch attempt was made. The vulnerability was the ability to inject a graph setting name that lead to sql injection when stored in the database and remote code execution when pulled and passing arguments off to rrdtool. The problem was that fixes were not made to all fields, a new patch was made to include the size value. The size value was not properly parsed and was not validated to be a proper float data type. A patch has been made to check if field values that are supposed to be int/floats are actually int/floats and that size is a float before being passed to rrdtool as a command line option.
A patch has been made and is available upstream in the testing branch. It is recommended to patch this vulnerability as soon as possible. You can do this by either manually applying the patches provided by Cacti or pulling the update from your upstream testing branch.
iPython notebook software is a web-based IDE that allows easy integration of formulas, graphs, code execution (and output), and etc. in an easy to use format that can be exported to file formats such as PDF. The notebooks are mostly used in educational circles that need to provide an easily digestible format for readers. More information of target scope can be found at:
A vulnerability was recently discovered where the MathJax library could be accessed over an unencrypted session to an external CDN. This library can then be hijacked and replaced/modified by an attacker on the fly. This does require the attacker to be able to manipulate traffic which generally is a man in the middle attack.
The ‘kernel’ context here means the iPython notebook kernel and not ring 0 access. However, the attacker does have remote code execution.
A patch is currently not released. You can keep up with the updates and progress towards a patch with the original bug report at:
The first proposed patch is to bring MathJax library internal so it doesn’t need to access an external resource over a CDN. The second patch idea is to enforce HTTPS when attempting to load the library. However, the first patch won’t fly due to the 40+MB file size and the second patch idea won’t work if the library can be loaded over HTTP at all. The external resource would have to enforce proper HTTPS.
Another issue is that iPython notebook is often ran from localhost. In this case, most people do not use valid certificates and just use self-signed certs for cost and ease. If a self-signed certificate is used then remote code execution still exists.
If you are using iPython notebook software, it would be best to block access to the MathJax library locally so it never makes the request. One could also remove the portion of code responsible for bringing in the library. However, both of these options might disable required functionality. Instead, the best bet is to use a HTTPS enforcement plugin like HTTPS-everywhere for Firefox and create a rule to disallow HTTP access. A tutorial on doing this can be found at:
One could also setup HSTS (https strict transport security) rules with HTTP headers to also not allow non-https data to be loaded in the origin. Whatever option you go with, the weakest link of not using self-signed certs must be taken care of. This can be cheaply removed by adding yourself as a CA, signing your own certs, and adding the CA to the browser that you use iPython notebook with. A guide on doing this with OpenSSL can be found at: