On Tue, Feb 14, 2012 at 7:16 PM, Jamie Strandboge <[email protected]> wrote: >>> * get_crash_db_url(): needs to verify the url. Granted, it should be >>> tightly controlled via the initscript or the root user, but still. >> Verified how? I could ensure there's an http:// on the front and a NUL >> terminator on the end, but beyond that I'm unsure what else we could do. > > Verified in a manner that will allow whoopsie to fail gracefully when > faced with invalid input. Checking for http:// or https:// and is nul > terminated is probably good enough, since this is administrator > controlled.
Fixed in r167. >> Is that really sensitive information to begin with? It's the > systemUUID. I can't envision an attack vector that involves it. > > Well, this was more of a thought provoking comment than a firm > recommendation. The file is only accessible by root, but I couldn't > really think of an attack vector that would expose this via whoopsie > where the user was non-privileged that didn't require physical presence. > I might not have been creative enough, but it is easy enough to remove > later if needed. Sure. Paranoia wins here :). I've removed the call to disabling secure memory (r165). > Hmm, well, /var/lock also has 1777 permissions, so this didn't address > the issue. What I meant was create the directory /var/local/whoopsie, > and put your lock file in there. Doing this is enough to fix both the > TOCTOU and the DoS. Done (r166). >> Given that /var/crash is world writable, why does this matter? Just > trying to understand what I'm defending against. > > Because it is world writable, people can put anything they want in there > and whoopsie could process it. As such, whoopsie needs to be coded > defensively since it is processing untrusted and unfiltered content. > While is is excellent that whoospie is running as non-root at this > point, we still want to make sure that it handles invalid input > gracefully such that whoopsie won't crash or be subverted into executing > arbitrary code. I'm not sure I understand the TOCTOU you are referring > to here-- we just want parse_report() to fail gracefully in the presence > of invalid input. Once it is uploaded to the server, the server will of > course need to do its own input validation. Apologies for being unclear, I was asking why it matters from a security perspective whether whoopsie is following symlinks or reading from block devices when /var/crash is world writable and any user can feed it anything they so desire (read-only and as a regular user, of course). The TOCTOU I mentioned is that presumably an attack could replace a regular file in /var/crash with a symlink between the calls to g_file_test and g_mapped_file_new. > I was not clear here. I was trying to say that the policykit parts were > done correctly. Sorry for the confusion. No worries! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/913694 Title: [MIR] whoopsie-daisy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/913694/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
