|
From: Dirk M. <dm...@gm...> - 2008-11-19 23:58:14
Attachments:
valgrind-cve-fix.diff
|
Hi, valgrind reads by default a .valgrindrc from the $PWD. in case you run binary from a publically writeable directory on a multi user machine, any other user can install you a config file and possibly execute code under your user (via the db-command and db-attach=yes). this is a bit related to a gdb vulnerability pointed out some years ago and fixed back then. I've ported the same patch idea to valgrind, namely to reject any .valgrindrc which is not owned by the user or is world writeable. This is CVE-2008-4865, which is already public. Patch below, ok for commit? Greetings, Dirk |
|
From: Nicholas N. <nj...@cs...> - 2008-11-20 03:17:10
|
On Thu, 20 Nov 2008, Dirk Mueller wrote: > valgrind reads by default a .valgrindrc from the $PWD. in case you run binary > from a publically writeable directory on a multi user machine, any other user > can install you a config file and possibly execute code under your user (via > the db-command and db-attach=yes). > > this is a bit related to a gdb vulnerability pointed out some years ago and > fixed back then. I've ported the same patch idea to valgrind, namely to reject > any .valgrindrc which is not owned by the user or is world writeable. > > This is CVE-2008-4865, which is already public. > > Patch below, ok for commit? Sounds like a good idea. Three comments: - In the docs, can you briefly explain why it's not read? - Is it worth printing a warning message if it's not read? - A test would be nice. You can use the "prereq:" and "cleanup:' lines in the .vgtest file to create and delete the .valgrindrc file. Thanks! Nick |
|
From: Dirk M. <dm...@gm...> - 2008-11-21 01:08:29
|
On Thursday 20 November 2008, Nicholas Nethercote wrote: > - In the docs, can you briefly explain why it's not read? Yes, but I don't want to go too much into the details because one usually doesn't document how to exploit possible security issues ;) > - Is it worth printing a warning message if it's not read? I think that's a good idea, added. > - A test would be nice. You can use the "prereq:" and "cleanup:' lines in > the .vgtest file to create and delete the .valgrindrc file. I'm not sure how to do that, given that the testsuite doesn't run as root, so I can't actually change the owner for testing purposes. or do you mean a verification that under normal conditions the file is still read? Greetings, Dirk |
|
From: Nicholas N. <nj...@cs...> - 2008-11-21 09:24:41
|
On Fri, 21 Nov 2008, Dirk Mueller wrote: >> - A test would be nice. You can use the "prereq:" and "cleanup:' lines in >> the .vgtest file to create and delete the .valgrindrc file. > > I'm not sure how to do that, given that the testsuite doesn't run as root, so > I can't actually change the owner for testing purposes. Oh, right. Then don't worry about it. Nick |
|
From: Julian S. <js...@ac...> - 2008-11-21 10:51:33
|
On Friday 21 November 2008, Nicholas Nethercote wrote: > On Fri, 21 Nov 2008, Dirk Mueller wrote: > >> - A test would be nice. You can use the "prereq:" and "cleanup:' lines > >> in the .vgtest file to create and delete the .valgrindrc file. > > > > I'm not sure how to do that, given that the testsuite doesn't run as > > root, so I can't actually change the owner for testing purposes. > > Oh, right. Then don't worry about it. Yeh, sounds good to me as it stands. Pls commit. J |