Red Hat Bugzilla – Bug 578119
CVE-2010-1100 Arora: Intended port restrictions bypass due integer overflow
Last modified: 2016-03-04 06:57:43 EST
Common Vulnerabilities and Exposures assigned an identifier CVE-2010-1100 to the following vulnerability: Integer overflow in Arora allows remote attackers to bypass intended port restrictions on outbound TCP connections via a port number outside the range of the unsigned short data type, as demonstrated by a value of 65561 for TCP port 25. References: [1] http://www.securityfocus.com/archive/1/archive/1/510283/100/0/threaded Public PoC: [2] http://vimeo.com/10302434
This issue is NOT reproducible with QtWebKit as found in latest Fedora updates (Qt 4.6.2). There's a check in QUrl code. Arora output while trying to connect to http://localhost:65561/ QUrl::setPort: Out of range Other WebKit implementations could be still vulnerable.
webkitgtk-1.1.15.4-1.fc12 with midori gives: (midori:17258): libsoup-CRITICAL **: soup_address_new: assertion `SOUP_ADDRESS_PORT_IS_VALID (port)' failed (midori:17258): libsoup-CRITICAL **: soup_socket_connect_async: assertion `priv->remote_addr != NULL' failed where soup defines: #define SOUP_ADDRESS_PORT_IS_VALID(port) (port >= 0 && port <= 65535)
Konqueror (KHTML based) is not vulnerable to port overflow but does not check port 25 at all.
I'm closing this. The summary of findings: - arora using QTWebKit - Port number integer overflow is caught as mentioned in comment #2. However, arora/QTWebKit does not use port blacklisting. - webkitgtk - Port number integer overflow is caught by libsoup network backend (see comment #3). Port 25 itself is blocked. - konqueror/khtml - Port number integer overflow is caught, default of 80 is used when out-of-range number is specified. As with arora/QTWebKit, there's no port blacklising in use at all.