On 3/10/2014 10:27 PM, Nico Kadel-Garcia wrote: > On Fri, Oct 3, 2014 at 1:44 AM, Brad Cable <[email protected]> wrote: >>>> repeated access attempts to break in again. "cron" was changed so daily >>>> backups were done after they down loaded all new files. "crontab -e" no >>>> longer worked. >>>> We made a copy of the OS onto old disk and removed disk from the system. >>>> There were so many charges to the OS and files in /etc that we did not even >>>> try to repair it. There were 1000's of differences between new install >>>> and >>>> copy of old system. >>>> >>>> I personally think the bash problem is over blown because they have to get >>>> threw modem, firewall, ssh before they can use "bash". >>> >>> That is *one* instance, and not really relevant to the circumstances >>> you described. In fact, many systems expose SSH to the Internet at >>> large for "git" repository access, and for telecommuting access to >>> firewalls and routers. The big problem with "shellshock" was that >>> attempts to restrict the available commands for such access, for >>> example inside "ForceCommands" controlled SSH "authrozed_keys" files, >>> could now broken out of and allow full local shell access. Once you >>> have *that* on a critical server, your hard crunch outershell is >>> cracked open and your soft chewy underbelly exposed. >> >> Does git-shell use bash at all for its execution? Shouldn't git-shell fix >> most >> of these issues? > > I'm not sure git-shell wouldn't fix this issue, but introduce a raft > of configuration issues. I was referring to the commonplace use of the > SSH 'ForceCommands' option o restrict operations by a shared service > account, such as the SSH credentials used for > '[email protected]:/username/reponame" access, and even Github reported > vulnerability to this problem for some accounts. The use of > 'git-shell' for such "shared" service accounts is an intriguing > approach I've not personally tried: thinking about it, it *sounds* > like it might work wel. I'm quite curious how Github and Bitbucket > and git.centos.org do it. Github, at least, did report partial > vulnerability, which the've addressed. > > It wouldn't do bupkiss for most svn+ssh or rsync over SSH backup setups.
rsync actually has an 'rrsync' utility in /usr/share/doc/rsync-x/support/ It is preferred to use this as the ForceCommand section of ssh config. This prevents getting a full shell and (should) resolve this issue. -- Steven Haigh Email: [email protected] Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897
signature.asc
Description: OpenPGP digital signature
