security projects thoughts

[Bayard Bell]

On 18 Apr 2011, at 06:29, Thomas de Grivel wrote:

> Le 04/16/11 20:56, Jordan K. Hubbard a écrit :
>> 
>> Heh.  That is an interestingly self-canceling argument.  "If you are not willing to go out of your way to facilitate my own unwise usage of the machine in a completely unsecured environment, then you are a baaaaad security professional!" ;-)   To those watching this discussion from the cheap seats:  Please don't do that.  If you must use untrusted wifi environments, and we all find that necessary from time to time, then either confine that usage to scenarios where information leakage / MITM attacks don't particularly matter (looking for a map on google maps or a restaurant on yelp) or use a frickin' VPN set to route *all* of your traffic!  That's what VPNs are for!  Learn from the whole firesheep saga!   Sorry, erm,</rant>.
> 
> This is not about trusting the environment but about who you are actually letting modify your data and thus the installed ports. Without cryptographic signatures, anyone controlling the network can. Whether they own it, work as admins, or just hacked it.
> 
> The network operator should definitely not be allowed to inject code into my system.

I agree with the sentiment, but I'd say that the more likely vector for a lot of people in this community isn't a compromised or untrusted local network but a name service attack like Kaminsky that allows them to impersonate rsync.macports.org. My experience of broadband routers is that a lot of them will default to acting as DNS servers to their DHCP clients, and I'd expect that few of these have the DNS changes that were rolled out a few years ago to resist cache poisoning. If we're going to talk in scenarios, we should treat this as a standard exercise in risk management, which is to weight things that have higher probability and highly damaging consequences. Low-probability, high-impact events can be dealt with after someone builds a bunker in an undisclosed location for us. ;->

The point nevertheless stands that input from the network shouldn't be turned right into directives for building software, whether by root or otherwise (there's enough room for privilege escalation with local access that you need to provide some basic integrity checks so you're left trusting the porter, the source, and macports). The ease of such compromises nevertheless points to acquiring key material used for subsequent integrity checks using anchors already on the system (e.g. certificates signed by a CA already on the system keyring and https for server authentication and communications integrity). If you want an example of something that can resist networking tampering either through something like session hijacking or cache poisining, you need look no further than Software Update, which uses signing and transfers over http and can at least know junk when it sees it, which is where you're proposing to set the bar.

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/20110418/99b7ad34/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/20110418/99b7ad34/attachment-0001.bin>