[<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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
