security projects thoughts

Bayard Bell buffer.g.overflow at googlemail.com
Fri Apr 22 07:14:53 PDT 2011


On 22 Apr 2011, at 06:02, Thomas de Grivel wrote:

> "Remote execution of arbitrary code" ? I picked sudo as an example but without signing it is also possible to replace any package to run any code and install it in the system as setuid if the Makefile says so. sudo is just more discreet as it already is setuid.
> 
> Unless you ensure some trust with the sources, for example by signing them with public crypto, you are fetching, compiling, and using code from a source possibly unknown to MacPorts.

Thomas,

I want to re-state this only in the interest of concluding what the threat model should be. The problem is closer upstream than the ports you are building: an attacker can exploit name services to have macports fetch its source and ports data from an arbitrary location. Security mechanisms can be stripped out, arbitrary content can be injected at any level. There's no need to be conventional and corrupt the ported content per se: you could add a destroot action to the Portfile that installs a rootkit, and hope that gets packaged up and redistributed to package rather than port users. You can look at the port contents, rebuild them from pristine sources, compare checksums and conclude that there's nothing wrong, missing that the injection is considered excelsior. Or you can do equivalent harm by injecting into the base.

I think Jordan's notes have got this right: you need to close the injection vectors first and protect the base of the system, and the risk you'd accept by passing on this is as much a question of reputation as anything else (i.e. if the retrospective conclusion is that competing products, even indirectly competing products, don't have these kinds of holes, the project suffers a huge setback). It's not that I don't value source integrity, but what we end up with is a system that can at least provide reliable source verification, where much of the residual problem needs to be fixed upstream. Does that make sense?

Cheers,
Bayard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110422/850110db/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110422/850110db/attachment-0001.bin>


More information about the macports-dev mailing list