Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 Jan 2016 14:53:57 +0100
From: Guillaume Ayoub <guillaume.ayoub@...ea.fr>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request for radicale

(Sorry if this mail is not in the original thread, I wasn't following 
the mailing-list before today)

Hi,

I'm the main developer of Radicale, I've merged the different fixes, 
but I'm not the author of these fixes. So, I know the software quite 
well, but I'm definitely no security expert.


That being said, here are for me the 3 real independent vulnerabilities 
reported and fixed in 1.1:

1. "The multifilesystem backend allows access to arbitrary files on all 
platforms."

This storage backend is not the default backend used, it's even marked 
as "not ready for production" in the configuration file. But when used, 
this backend could allow anybody to read/write anything anywhere, by 
sending requests with particular paths and contents.

2. "Prevent regex injection in rights management."

If an attacker is able to authenticate with a user name like .*, he can 
bypass read/write limitations imposed by regex-based rules, including 
the built-in rules called owner_write (read for everybody, write for 
the owner of the calendar) and owner_only (read and write for the owner 
of the calendr).

3. "On MS Windows the filesystem backend allows access to the first 
level of files on a drive."

The filesystem backend is the default storage backend. When used, it 
converts paths like /c:/filename/dummy to c:\filename, and allowing 
anybody to read/write anything anywhere, by sending requests with 
particular paths and contents.


For me, the other ones are theoretical vulnerabilities, but I'm not 
sure that they can lead to real life consequences:

- "Paths like .., ../.. or // are not sanitized correctly". But when 
translated into a filesystem path, I think that it could only enable to 
read/write files in the default storage directory, like "normal" 
requests do.

- "The program crashes if a path doesn't start with base_prefix instead 
of showing an error message." It was actually raising an exception, but 
didn't "crash". That's bad for sure, but not related to security.

- "Improve the regex used for well-known URIs." It wasn't really 
harmful because of Radicale's code at this moment, but may have become 
a problem later.

- "Decouple the daemon from its parent environment." Always a good 
idea, but I can't find a related possible attack.

- "Avoid race condition in PID file creation." No possible attack for 
me.

- "Prevent crafted HTTP request from calling arbitrary functions". In 
real life, no way to attack because of the signature of the other 
methods, but may have enabled an attacker to call a method called "a" 
by sending an HTTP "a" request, if "a" had had the good signature.


Hope that it helps!

Regards,
-- 
Guillaume Ayoub
Kozea - Directeur associƩ

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ