Security quotes of the week [LWN.net]

Hadoop has a huge set of dependencies, and little of this has been seriously audited for security - and in particular not in a way that would allow you to check that your binaries are built from this audited code anyway.

There might be functionality hidden in the code that just sits there and waits for a system with a hostname somewhat like "yourcompany.com" to start looking for its command and control server to steal some key data from your company. The way your systems are built they probably do not have much of a firewall guarding against such. Much of the software may be constantly calling home, and your DevOps would not notice (nor would they care, anyway).

The mentality of "big data stacks" these days is that of Windows Shareware in the 90s. People downloading random binaries from the Internet, not adequately checked for security (ever heard of anybody running an AntiVirus on his Hadoop cluster?) and installing them everywhere.

— Erich Schubert (Thanks to Paul Wise.)

Two points here. The first is that the FBI should stop treating Stingray like it's a big secret, so we can start talking about policy.

The second is that we should stop pretending that this capability is exclusive to law enforcement, and recognize that we're all at risk because of it. If we continue to allow our cellular networks to be vulnerable to IMSI-catchers, then we are all vulnerable to any foreign government, criminal, hacker, or hobbyist that builds one. If we instead engineer our cellular networks to be secure against this sort of attack, then we are safe against all those attackers.

— Bruce Schneier

There are no silver bullets in Internet security — no way to kill the monster in a way that it stays dead. We in the Internet security business look for current attacks and learn from those how to detect and prevent those attacks and maybe how to predict, detect, and prevent what's coming next. But rest assured that there is no end game — we put one bad guy in prison for every hundred or so new bad guys who come into the field each month.

There is no device or method, however powerful, which will offer a salient defense for more than a short time. The bad guys endlessly adapt; so must we. Importantly, the bad guys understand how our systems work; so must we.

— Paul Vixie

to post comments

Security quotes of the week

Posted May 1, 2015 2:37 UTC (Fri) by angdraug (subscriber, #7487) [Link] (5 responses)

People downloading random binaries from the Internet, not adequately checked for security (ever heard of anybody running an AntiVirus on his Hadoop cluster?) and installing them everywhere.

You don't say. RVM is my favorite example so far:

curl -sSL https://get.rvm.io | bash

Security quotes of the week

Posted May 1, 2015 3:12 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Meteor is another one. I love how all of them assume sudo works though (I never set it up on my machines).

If there's one glint of shiny in the pile of crap, you can download and edit them to not install to global directories and instead shove them in their own custom prefix.

Security quotes of the week

Posted May 1, 2015 6:01 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (2 responses)

That's exactly as (in)secure as some other popular methods of installing $random_software from $random_developer:

sudo add-apt-repository ppa:user/$random_software
sudo apt-get update
sudo apt-get install $random_software

sudo rpm -Uhv https://web.site/$random_repo.rpm
sudo yum install $random_software

wget https://web.site/$random_software.tar.xz
tar xJf $random_software.tar.xz
cd $random_software
./configure && make && sudo make install

In all three cases you're handing control over to some piece of downloaded software as root, and that piece of software can do anything at that point as both Debian as well as RPM packages allow arbitrary shell scrips/commands to be run during installation. The build system for any piece of software most certainly does, too.

Even if you don't invoke root at this point by running everything as a normal user there's often not a real gain in doing so. On my machines I am the only user, meaning that any piece of valuable information is accessible by my normal user as well. So for me, on those machines, running as $normal_user can be just as damaging as running as root.

So unless you only compile the whole software (not just the installation step) in some kind of sandboxed environment there's not that much to be gained from not running as root.

But even if you do that it comes back to the point that the information accessible with my $normal_user is what I would have to protect. So even if I compile and install in a very safe way, what happens when I run the resulting software as $normal_user? Again I hand over control to some random piece of code. We currently have very little possibilities to sandbox random software in a meaningful and effective way. Things like Docker and the recent initiative borne out of GNOME about sandboxing GUI applications may one day lead to improvements, but where nowhere near that. Things are somewhat different and even better for server-type applications, but not for user apps.

It all boils down to some basic level of trust. Do I trust $random_developer enough not to mess with me and my data? If I don't then I must not run anything from him/her, no matter how. Because I cannot sandbox it effectively. However, if I do have that trust then I can often just as well pipe content from a website directly through a shell because the other at least somewhat convenient methods aren't any more secure.

Security quotes of the week

Posted May 3, 2015 15:33 UTC (Sun) by kleptog (subscriber, #1183) [Link]

I would argue that the first choice is marginally better because it at least checks your connection wasn't man-in-the-middled. The packages are built by trusted buildbots which hopefully deals with buildchain issues.

It doesn't distract from your main point though, that you have to trust the actual developers writing the code to not do stupid things. When downloading source from the internet I try as much as possible to verify md5sums so that it's just the developers I need to trust and not the whole internet.

I do await the day that software is distributed as something like Dockerfiles which build and run stuff in containers so I don't even have to trust them completely.

Security quotes of the week

Posted May 6, 2015 16:48 UTC (Wed) by ScottMinster (subscriber, #67541) [Link]

How about for number 3 you do something like:

./configure --prefix=$PWD/linux && make all install > makeout.linux 2>&1

That's a habit I've gotten into. Sure, something in the configure script or makefile could wipe out my home directory or start a spam bot, but it's not going to do so with the help of a hard to remove rootkit.

The danger of running unknown things as root is that it could compromise your entire system, making it that much harder to fix. At some point, it's about trying to minimize the damage, not completely prevent it.

You're right that adding a PPA or other repository means you are placing your trust in those entities, and that should be done with care, because they could completely own your system.

Interestingly, some of the LibreOffice builds I've downloaded for Linux use rpm with custom DB using the --dbpath option. This allows the packages to be installed as a non-root user. This is nice for environments where you don't have root access.

Security quotes of the week

Posted May 4, 2015 12:34 UTC (Mon) by mgedmin (guest, #34497) [Link]

http://curlpipesh.tumblr.com

There are a lot of those.