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

Paul Harvey csirac2 at gmail.com
Thu Jul 30 06:36:28 UTC 2015


On 30 July 2015 at 16:30, James Ring <sjr at jdns.org> 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, 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.


Which begs the question: if giving tutorial users instructions to do
the PGP/shasums dance is the alternative, that's information which
will be delivered over https anyway, and if it's good enough for one,
why not just pipe it to a shell in the first place...

.. some responses to this line of thinking are mentioned in the
Georgiev paper, curl/wget & friends don't do cert pinning etc. but at
the end of the day, you really have to pick your battles. On this
occasion perhaps the hypothetical scalpel that's been splashed with a
bit of hot water (referring to Scott's reply earlier) is actually not
the worst that could happen in this case :-)



More information about the linux mailing list