On 3/10/2014 10:27 PM, Nico Kadel-Garcia wrote:
> 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.

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: [log in to unmask]
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897