Sean Cassidy

No, I'm sorry, I seriously don't understand how that applies in this case. How is "trusting the content you get from `apt-get`/`dpkg`/`pacman`" safer than curling-to-bash? In both cases, you are downloading and installing content from a trusted source (assuming you are curling via https to avoid MITMs). In the curl-to-bash case, you have the _ability_ to at least inspect the code first before you install it (though, realistically, how many folks would really have the dedication and the ability to do so?), whereas with package managers you're installing "blind". Doesn't that make curling-to-bash the _safer_ option?

I clearly must be missing something, here, because everyone decries "curling-to-bash" as a bad security practice, but I haven't seen an explanation of _why_. I tried doing some research for myself - this page[1] suggests that package managers have built-in checksumming and signature verification, but then goes on to propose an attack vector where the load balancer is compromised, so (presumably?) those same checksums/signatures could also be intercepted and faked. This gist[2] has a lot of people speaking against it, but from following those links, the only downside I could see was here[3], pointing out that the shell will keep executing if a connection closes mid-stream - which, yes, is certainly a bad thing and a good argument to use package managers, but not what I would call a security concern (unless you don't trust the entity on the other end of the stream -…

> Aren’t abstractions supposed to make things easier to learn?

Not always. Some abstractions are designed to make it easier to solve hard problems correctly (than without the abstraction).

For example, consider Rust's memory model. Many people criticize that model as difficult to learn. By comparison, you might argue that C's memory model is simpler to learn. Yet, the C approach to allocating, using, and freeing memory is highly error-prone. C programs historically have frequently had mistakes such as use-after-free errors, or buffer under/overflow/reuse errors. The high-profile OpenSSL Heartbleed vulnerability was an example of a weakness in C's memory model and memory handling abstractions [1].

Rust's memory model may be more difficult to learn than C's, but once learned, they are abstractions that provide an advantage in building correct software, by ruling out certain classes of mistakes. (GC in languages like C# and Java and Go can also prevent these mistakes, but comes with a runtime cost. Rust aims to provide zero-cost abstractions.)

Building correct async IO programs using kernel abstractions is difficult for similar reasons as it's difficult to write correct programs with C's memory model. It's especially difficult if you want the async IO program to be portable across multiple OS/kernels. I have not used Tokio, but I would guess that its Rust-powered abstractions will make it difficult or impossible to leak memory or sockets, or to fail to handle error cases…

> No true blogger would wilfully misunderstand a buffer overrun vulnerability in order to score some cheap pageviews.

You may want to read up on Ted, and realise that when he writes

> if we don’t actually understand what vulnerabilities like Heartbleed are

he's probably talking about you.

> Basically, he's explicitly re-using a buffer, no buffer was overrun.

Which is essentially what happened in heartbleed. Heartbleed was not a buffer overrun at any point.

Here's the tl;dr: during heartbeat, OpenSSL would malloc both input and output buffers at the caller-specified size (65536 bytes), copy a caller-provided input (1 byte) to the input buffer then copy the whole input buffer to the output buffer.

Anything beside the overwritten byte would likely be previously written data since neither malloc nor free zero out their stuff by default[0], essentially leaking 65k of random data every time.

This was compounded by OpenSSL doing its own memory management via freelists, making it even more likely interesting data would be present in the input "garbage" and precluding OS mitigations (such as BSD's malloc.conf framework[1]), not to mention the unmitigated (no freelist) codepath had bitrotted and didn't actually work even if you knew how to enable it[2]. Note that [1] and [2] are by TFAA, and that he's an OpenBSD and LibreSSL core contributor.

[0] http://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html

[1]…

>purportedly a bit more secure?

The worst bugs in LastPass are:

1. Four months ago a bug was discovered by project zero[1] about how all of your passwords can be stolen just by making a user visit a webpage. Moreover, any code can be executed remotely, compromising your entire computer. Discussion[2]

2. Later on the day vulnerability (1) was published, another was found. Project zero bug report. [3]

3. Last year a software engineer who wasn't a security researcher found a bug[4], which again, gives all your passwords.

4. The bug in (3) wasn't fixed properly, which lead to this [5]

Other bugs, but not as terrible as the ones I listed above

Jul 27 2016 [6]

Mar 25 2017 [7]

Jun 17, 2015 [8]

Nov 17, 2015 [9]

You are also forgetting a whole another class of attacks -
Phishing [10]

[1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=1209

[2]: https://news.ycombinator.com/item?id=13924737

[3]: https://bugs.chromium.org/p/project-zero/issues/detail?id=1217

[4]: https://labs.detectify.com/2016/07/27/how-i-made-lastpass-give-me-all-your-passwords/

[5]: https://bugs.chromium.org/p/project-zero/issues/detail?id=1188&desc=2

[6]: https://bugs.chromium.org/p/project-zero/issues/detail?id=884

[7]: https://bugs.chromium.org/p/project-zero/issues/detail?id=1225&desc=6

[8]: http://www.businessinsider.com/security-expert-describes-lastpass-vulnerabilities-posted-to-pastebin-in-2013-2015-6

[9]:…

The problem is that there's a lot of software out there that expects you to install it this way - particularly by piping into sh or bash or the like. See also http://www.seancassidy.me/dont-pipe-to-your-shell.html and http://output.chrissnell.com/post/69023793377/stop-piping-curl1-to-sh1 and https://www.chef.io/blog/2015/07/16/5-ways-to-deal-with-the-install-sh-curl-pipe-bash-problem/ . There was also a blog out there collecting instances of this, but I couldn't find it again after a couple searches.

I had to hold my nose and paste some commands like this in order to reinstall Composer [1] and Drupal Console [2] earlier this week. Ugh, it feels so dirty, but it's often the first and/or the easiest, if not the only, way that software like this documents how it's to be installed.

1. https://getcomposer.org/doc/00-intro.md#globally

2. http://drupalconsole.com

I'm pretty sure the OP is intentionally not doing this because piping commands/things-from-the-internet into "bash" (or anything else) is generally considered bad practice.

For me, I'm all for this. Anyone that is aware of the security implications is extremely likely aware of how to make the conversion like you've provided. In that case, no reason to tell people, because they already know. But it's not a great thing to tell noobies to do because they will get burned. So don't tell them. As they advance they'll naturally learn about this feature. And hopefully they have learned the implications by the time they learn how to do this.

(not me): https://www.seancassidy.me/dont-pipe-to-your-shell.html