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"

Powered by blists - more mailing lists