bugtraq - Re: Perforce client: security hole by design

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 11 Jan 2007 11:27:50 -0800
From: Crispin Cowan <crispin@...ell.com>
To: Ben Bucksch <news@...ksch.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Perforce client: security hole by design

Ben Bucksch wrote:
> = Abstract =
>
> The Perforce client has a huge gapping security hole by design. It
> totally trusts the Perforce server and does whatever the server tells
> it, writing arbitrary files.
Eww :)

> = Risk =
>
> Critical. The server has full access to *all* files that *any* of its
> users has.
>
> "We can trust the server" is not an appropriate answer:
>
>   * I am a contractor and have access to many companies' sources, and
>     I do *not* allow any company I work for to have full access to all
>     files on my computer, including the source of the all other
>     companies I work for and even personal files.
You could use any of the security policy systems (AppArmor, SELinux,
LIDS, etc.) to confine the client to be only able to access the files
you want it to have access to. I would argue that AppArmor is the
easiest tool to achieve that (but I'm biased) as it directly supports a
policy model of "this program gets to access these pathnames" e.g.
here's the confinement profile for ntpd:

/usr/sbin/ntpd {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability ipc_lock,
  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_chroot,
  capability sys_resource,
  capability sys_time,

  /drift/ntp.drift rwl,
  /drift/ntp.drift.TEMP rwl,
  /etc/ntp.conf r,
  /etc/ntp/drift* rwl,
  /etc/ntp/keys r,
  /etc/ntp/step-tickers r,
  /tmp/ntp* rwl,
  /usr/sbin/ntpd rmix,
  /var/lib/ntp/etc/ntp.conf.iburst  r,
  /var/lib/ntp/drift rwl,
  /var/lib/ntp/drift.TEMP rwl,
  /var/lib/ntp/drift/ntp.drift r,
  /var/lib/ntp/var/run/ntp/ntpd.pid w,
  /var/log/ntp w,
  /var/log/ntp.log w,
  /var/run/ntpd.pid w,
}

AppArmor will also let you change the policy for a running process on
the fly, so you could edit the file and push the policy-reload button as
you move between one work site and another without even having to
restart your Perforce client. AppArmor is GPL and available for SUSE,
Slackware, Ubuntu, and Gentoo.

>   * Also, there are many ways to fool DNS, so that your client goes to
>     another, hostile server.
>   * And, lastly, a server is not 100% bulletproof either.
Agreed. An agent that totally trusts a remote computer is dangerous, and
you shouldn't do that unless absolutely necessary.

Crispin

-- 
Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hacking is exploiting the gap between "intent" and "implementation"