full-disclosure - 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] [thread-next>] [day] [month] [year] [list]

Date: Thu, 04 Jan 2007 03:23:27 +0100
From: Ben Bucksch <news@...ksch.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Perforce client: security hole by design

Anders B Jansson wrote:
> I'd say that it's a design decition, not sure that it's a design flaw.
> It's all down to what you try to protect.
> ... connecting any device not 100% controlled by the company to a company network is strictly forbidden, doing so would be regarded as intended sabotage.
>   

OK, so this bug is not a problem in your company or some Perforce 
setups. That's fine. However, I hope it was clear from my description 
that it's *not* fine in other cases:

    * remote contractors like me with their own machine who work for
      many companies and don't feel like having 20 boxen, on separate
      networks.
    * I've seen quite some startup companies who actually required their
      employees to bring their own computers, because the company didn't
      have money yet. Neither had the employees. What about their
      personal data?
    * As far as I can see, the FreeBSD project uses Perforce for some
      project parts [1],[2]. I'm quite sure they don't hand out
      computers to all relevant committers. In fact, that Perforce
      server is running against the Internet
      (perforce.freebsd.org:1666), so anybody cracking that machine
      might break into developers' machines. And, worst case, go on from
      there.
    * There are public Perforce servers for anonymous access. That's
      comparable with public FTP or HTTP servers. Surely you'd be upset,
      if a random FTP server would have access to your files just
      because you downloaded something.

In all these cases, this is a critical flaw for the Perforce user. Flaws 
on ebay.com for ebay users are still flaws.

I understand the reasoning of Perforce's design, and I understand that 
most companies think that their *own* servers are fine and never pose a 
problem to *anybody*, why *would* they, but that's just not a valid 
assumption for the rest of the world.

> IT director chosing Y would say "I chose a highprofile proffessional 
> company with a good security track record".

Sometimes, the track record is only good because nobody looked into it.

Ben

[1] http://www.freebsd.org/platforms/mips.html
[2] http://people.freebsd.org/~scottl/p4-primer.txt

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/