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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ