julie78787

[Disclaimer: I work for AgileBits. I also started the #slack-murderer hashtag inside :slack: before we switched over. My opinions are my own. Just ask anyone at AG!]

"Slack is heroin" is pretty accurate. Instant communication (and video games, and Facebook, and Y-Combinator ...) feeds the gratification / pleasure parts of the brain. That's great if one is working on their own time and can enjoy the inevitable crash when everyone else has finally gone to sleep, but when you've got a company full of people flitting around like crazy, because their neurochemistry says they have to "keep up", because "keeping up" is what keeps the brain in a happy mood -- that's a bad thing.

Changing collaboration software won't do a damned thing until teams have a chance to attend Narcotics Anonymous meetings.

No, it's pretty spot-on.

People try to divide security vulnerabilities into "super-obviously-bad" and "no one will ever find / exploit / do much of anything with it."

The problem is that rather often little holes can be leveraged into bigger holes. The argument against the change I'd requested was that no one would ever write a program which would process the trace hook events. Because they just wouldn't. Except no one needed to - there was a program that took trace identifiers and dumped the events for all to see.

That's an argument to "difficulty to exploit". The same thing has happened with various race-related exploits -- a race that's fractions of a millisecond long is considered "unexploitable" until process scheduling, and how to control it via various means is discussed.

It doesn't matter the problem space - fixing bugs in code, configuring servers securely, proper OPSEC, choice of programming languages or development methodologies. It always comes down to security versus convenience. Sometimes "convenience" is replaced by "cost" or "resources". In this case, the NSA didn't have the "resources", which is a proxy for "convenience" because if giving Clinton a secure BlackBerry had been dead simple and free ("convenient") she'd have gotten one.

As for being "well-rehearsed", yeah, I've spoken publicly on security and try to make my little anecdotes fun to read or hear.

The problem is that quite often security professionals say "No", provide reasons, and the person doing the asking insists that convenience is more important than security.

My favorite story of all time, which I'll share because it's now over 20 years old, had to do with a security vulnerability in the diagnostic trace component of a serial device driver.

The developer in question insisted it had to be there. A meeting with the two of us, as well as our bosses, and a "neutral" odd-numbered party was had.

I started by explaining the exploit. The developer then explained the need to have support staff (who weren't "root" users") able to enable the diagnostic trace feature. I then explained how a non-support person could trace a specific TTY (see, it is an old story!) and capture an entire login dialog.

Things weren't going well for me, so I then explained that it presented a security vulnerability which I'd have to disclose.

At that point in time, the developer got up out of his chair, and came across the table at me. His boss grabbed him, sat him back down, then agreed with my explanation and the feature was changed to require privilege.

If you think being a security professional is fun, it's not all sunshine, roses and egotistical power-tripping. It's a constant struggle to say "No" when people want to make products more "useable" and we want to make sure they are "secure".

Except that you can attack stored encryption secrets either off-line, or with the same privileges as the user.

If they are hard-coded in the binary, they can be extracted off-line by another use with the same binary. If they are generated at run-time, they have to be stored with permissions that grants the user access to their own resource.

There are programming techniques for sharing a file descriptor, but they aren't portable. That makes generating a keypair, then sharing an open file descriptor to the file containing the keypair impossible.

But even if they could, UNIX domain sockets aren't immune to attacks. That sort of the problem with "First, assume your machine has been pwn'd".

Not necessarily. Malware only requires privilege if it is violating a security policy. There are a variety of attacks in which a process executing as a user is able to access resources controlled by other processes which are executing as the same user.

Correct - Least Privilege says you do the absolute least you need to do in order to make things work, so that any errors are limited to that one part of the system.

What's been done here by Wireshark isn't least privilege, or secure. Its like the opposite of least privilege and security.