Overview
Reference: CVE-2018-8828
We strongly advise you to update your Kamailio installation to the latest stable release for security reasons.
All supported releases (4.4, 5.0. and 5.1) contains two important security fixes related to the tmx and lcr module.
The issues were fixed before the 4.4.7, 5.0.6, and 5.1.2 releases (done on the 5th of February for the lcr module and on the 10th of February for the tmx module) in the respective stable branches. So if you are already running the 4.4.7, 5.0.6 or 5.1.2 release then you have already the fixes deployed. If you don’t use the tmx or lcr module, you are also safe.
If you can’t update to a new release for some reasons timely, there are also two configuration workarounds possible.
Technical details for the tmx issue
A specially crafted REGISTER message with a malformed branch or From tag triggers a so called “off-by-one heap overflow”. This vulnerability existed in the tmx module and allowed to remotely crash the Kamailio service. The exact location of the error was in the tmx_check_pretran(..) function in the file tmx_pretran.c.
If an attacker sends many of this messages this would lead to a Denial of Service of the attacked infrastructure. This is especially critical as no authentication for the remote source is needed.
This vulnerability was found from Sandro Gauci and Alfred Farrugia from Enable Security. Many thanks to them for finding the issue and reporting it to us.
You find all the details including a proof of concept code in the published security announcement from them: Link
Technical details for the lcr issue
A vulnerability existed in the lcr next_gw() function. It happens when a very long R-URI username is sent with an INVITE due to an mistake in the function error code handling. It can be triggered from a remote source, but should be only from a trusted peer, as it expected that calls going through lcr are authenticated by user or IP address.
This vulnerability was reported from an user in the Netherlands to us, thanks as well for the bug report.
Configuration workarounds
For tmx, a length check can be added before checking for re-transmissions (or at the beginning of request_route):
if($(ci{s.len}) + $(hdr(CSeq){s.len}) + $(ft{s.len}) + $(sel(v.branch){s.len}) >= 254) {
sl_send_reply("500", "Not accepted");
exit;
}
For lcr, the check should be on dialed number ($rU – r-uri username). The issue is exposed if the length of new request URI after lcr operations is over 256 (load_gws()+next_gw() — with strip and prefix operations, new host, port, params).
However, only $rU is used from incoming message, the rest of the attributes are taken from lcr database tables. A good check could be a max 32 length for $rU (this is supposed to be a telephone number, so it is a decent upper limit). If exceeding, the call should be rejected:
if($(rU{s.len}) > 32) {
sl_send_reply("500", "Not accepted");
exit;
}
Based on common usage out there, usual host names, port and parameters length should exceed 256. But if someone is having long values for those fields, they should double check if the limit is exceeded.
This check should be done before use of load_gws().
Remarks
Assigned CVE reference: CVE-2018-8828
So far we are not aware of any public exploits of these errors, even the faulty code in both modules was a few years old. But as already mentioned, we advise you to update your Kamailio servers to the latest stable release as soon as possible, especially as the tmx vulnerability will be reported to more security lists later today.
Please address any detailed technical questions related to the two bugs to the developer list at sr-dev@lists.kamailio.org.
For questions about the configuration workarounds please contact the user list at sr-users@lists.kamailio.org.
In case of confidential remarks related to this or other security issues, please address them to the Kamailio Management at management@kamailio.org.