All, I have not heard from anyone in the last hour, so I have shut down the Whimsy VM out of an abundance of caution until this issue can be assessed. I have verified at least one of the reports as legitimate (#3) however, all of these vectors -appear- to require authenticated access. I’m not able to vet the Ruby code so I can’t say for sure if there are vectors for non-authenticated users.
Any infra staffer can restart the whimsy-vm4 VM as needed once the situation is addressed. -Chris > On May 5, 2020, at 8:35 PM, Chris Lambertus <c...@apache.org> wrote: > > Whimsy project, please respond to root@ and security@ ASAP with your > assessment. The issues described by Daniel are quite serious, and may warrant > shutting down the system until the problems are addressed. > > > > > >> Begin forwarded message: >> >> From: Daniel Shahaf <d...@daniel.shahaf.name >> <mailto:d...@daniel.shahaf.name>> >> Subject: whimsy.a.o: Password disclosure, information disclosure, file >> creation >> Date: May 5, 2020 at 1:36:22 PM PDT >> To: r...@apache.org <mailto:r...@apache.org> >> Cc: secur...@apache.org <mailto:secur...@apache.org> >> >> [Cc'ing security@ because whimsy's technically a PMC] >> >> --- >> >> #1 >> >> https://whimsy.apache.org/committers/svn-info.cgi?url=svn%3A%2F%2Ffoo.example.org%2F >> >> <https://whimsy.apache.org/committers/svn-info.cgi?url=svn%3A%2F%2Ffoo.example.org%2F> >> >> If you click this URL now, you'll just get an HTML page that tells you >> svn had failed with SVN_ERR_RA_CANNOT_CREATE_SESSION + ECONNREFUSED. >> However, if I'd used a real URL in the query string and gotten some >> committer to access the above link authenticatedly, they'd have accessed >> a repository under my control with their LDAP credentials. This enables >> a password guessing attack. I suspect that it also enables a password >> leakage attack (i.e., that it'll happily send the password to the server >> in cleartext, if the server offers no fancier authn methods) but haven't >> verified this. >> >> The remote URL doesn't have to be an apache.org one. Even if it is, >> anyone with a shell account on a PMC VM can bypass that. Should >> whitelist to >> r'^https?://(?:svn|dist)\.apache\.org(?::443)?/repos/(?:asf|private|…)/', >> or better yet, use radio buttons to choose a repository and prompt for >> the in-repository path only. >> >> However, I'd sooner recommend to retire the page entirely. The best way >> for a CGI to use a user's password on their behalf is not to do it at all. >> >> --- >> >> #2 >> >> https://whimsy.apache.org/committers/svn-info.cgi?url=/x1/srv/whimsy/www/committers >> >> There's no reason for this to work. This may be an information >> disclosure vector — not only directly via the output when it succeeds, >> but also via whether the error is SVN_ERR_WC_NOT_WORKING_COPY (baseline) >> or EACCES (meaning the argument exists and is chmod'd). >> >> --- >> >> #3 >> >> https://whimsy.apache.org/committers/svn-info.cgi?url=--config-dir=/tmp/bobby >> >> Unconfirmed because I locked myself out of my account by accident, but >> if it works, it'd be a vulnerability whereby any committer can create >> directories anywhere on the VM with the permissions of the CGI script >> user. Then it can be used to DoS anything that relies on predictable >> filenames (probably including several other whimsy apps). >> >> It actually does escape the '=' sign, but I think that's not enough: >> «sh -c 'echo foo\=bar'» prints «foo=bar». >> >> --- >> >> The good news is that it escapes spaces. If it didn't, there'd be an >> arbitrary code execution vulnerability. >> >> You should probably double check that it escapes newlines, though. (And >> ampersands and pipes. I checked semicolons.) >> >> Daniel >
