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]
Message-ID: <459C651F.9020504@bucksch.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ