security projects thoughts

Thomas de Grivel billitch at gmail.com
Tue Apr 26 00:41:47 PDT 2011


On 04/22/11 16:14, Bayard Bell wrote:
> 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?

Quite clear, base is as vulnerable as ports. There is a chain of 
security from first installation through each upgrades and port 
installation.

The first base installation still has to be trusted but if that's the 
only step requiring a trusted network connection, all the way to 
MacPorts servers, this would be a true improvement.

Security is not my job but certainly a concern to me. I think it should 
always be as long as any service is provided.

I hope I was trolling useful, cheers to you all and thanks for MacPorts ;)

-- 
Thomas de Grivel
http://b.lowh.net/billitch


More information about the macports-dev mailing list