On Fri, Oct 3, 2014 at 1:44 AM, Brad Cable <[log in to unmask]> 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
[log in to unmask]:/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.