[clug] How you know your Free or Open Source Software Project is doomed to FAIL

Scott Ferguson scott.ferguson.clug at gmail.com
Thu Jul 30 11:49:51 UTC 2015


On 30/07/15 16:30, James Ring wrote:
> On Wed, Jul 29, 2015 at 11:23 PM, Alex Satrapa <grail at goldweb.com.au>
> wrote:
>> On 30 Jul 2015, at 16:05, James Ring <sjr at jdns.org> wrote:
>>> 
>>> The possibility that somebody out there is going to somehow 
>>> modify the encrypted shell script response in-flight is just not
>>> a concern to me. Also I'd think Google has more to lose by
>>> publishing bad scripts than I do running them.
>> 
>> It won’t be Google that publishes the bad script. By definition the
>> actor in the “Man in the Middle” attack is neither end of a
>> presumably two-way conversation.
>> 
>> You *think* you’ve connected to Google, but the attacker poisoned
>> your DNS so you’re actually connected to g00gle,


*su -c* curl/wget | bash  (I haven't checked that, consider it psuedo-code).

Poisoning his DNS 'can' be as simple as:-
echo '77.232.69.182 google www.google.com.au www.google.com
google.com.au google.com' >> /etc/hosts

Which will work, because if they can write to his certificate store they
don't need to have broken into a CA and have a fraudulent certificate
for google.com/.au

Just because a project is hosted by Google doesn't mean it's audited by
google. Just because you can verify your trust in a person that has
write access to project hosted at Google doesn't mean they (can)
maintain full control over the write access. At best trust in a person
means you believe you know how they will act on the basis of history -
it's not a measure of their control over their environments.


>> and the script
>> you’re piping into shell sets up a rootkit rather than an Internet
>> cat picture archive.
> 
> Well, they'd have to poison the DNS and also convince one of the 
> certificate authorities trusted by wget to issue a SSL certificate 
> with Google's name on it to the attacker.

Alex just pointed out what I was thinking when writing a response to
your post. He's right - hard as it maybe to believe (that's not a
comment about Alex, just fast typing on my part).

Can you name a CA that hasn't been compromised? It's a moot question -
all the major ones have *that we know*.

ARP poisoning and other exploits to re-route selected targets to malware
injection servers is not a theoretical possibility (it's been done - and
documented). I can think of one other possible way of achieving the same
result without having to break into a CA (though I won't publish the
idea here).

Don't make the mistake I listed amongst common failings in a earlier
email in this thread. You live in Canberra - it's full of high value
targets for attackers with a lot of resources. The easiest way to get
into a well-defended castle is not by battering against the main gates.
i.e. target someone who already has access. The common variation with a
higher probability of success (and evading detection) is to target
someone who is 2 (or 3) degrees from the front gates. Australia is not
the only country that has had the security forces ask for the legal
right to infect the computers of people who are not suspects with
malware (to indirectly gain access - "targets of opportunity").

The most likely risk there is of other entities making use of the same
"doors" that malware creates. Think Sony root-kits.

> 
>> Alex
> .
> 



Kind regards

--
"I use readability tools, I also try and employ critical thought, and I
rely strongly on proofreaders. I'm not a professional writer. I've used
none of those things when writing this, and it only "seemed" OK after a
quick re-read, except in this case where I didn't even do a re-read - my
apologies in advance for all the very likely errors."
~ standard weasel disclaimer



More information about the linux mailing list