Slashdot Mirror

In Firefox 57 there's now also the option to turn on its built-in tracking protection all the time, as opposed to only in private browsing mode.

You should do that anyway if for no other reason than to actually speed up the internet. http://www.ieee-security.org/T...

Since 2014 I've been reading about hardware-based detection. I'm starting to think this is just panacea... like those cloud-based antivirus engines that never picked up anything. Here's a bunch of research on the topic: http://www.ieee-security.org/T... http://caslab.eng.yale.edu/wor... http://www.cs.binghamton.edu/~... http://www.cs.binghamton.edu/~...

Please do not judge CS researcher by a single paper. BTW, this paper was not even the best paper at IEEE SP. (complete list with best papers at [1].)

From a quick read of the lava paper. It seems that the novelty aspect of LAVA is that the software can inject bugs automatically in complex codebase. So you no longer have a grad student writing obviously faulty code on a toy program or inserting a few bugs manually to test one or two software. LAVA allows you to insert a myriad of bug in a myriad of software to test border condition more accurately.

Clearly it is not the best idea of the decade, but it is a nice little tool/result.

[1] http://www.ieee-security.org/T...

It really doesn't matter to anyone except people who block cookies (and that's not you, because you're logged in). Those people are so rare, I don't think anyone's using any alternate method to track people. Cookies work well enough for tracking.

Actually there are commercial fingerprinting services. The Cookieless Monster does a good job at analyzing them. Many sites like Google, Twitter, Facebook and others mention the colleciton of "device information" in their privacy policies too.

In case you missed it on /. yesterday:

Half of Tor Sites Compromised, Including TORMail

Related:

Biryukov, Alex, Ivan Pustogarov, and Ralf-Philipp Weinmann, Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization, presented at the 2013 IEEE Symposium on Security and Privacy, May 19-22, 2013, San Francisco, California

If you want to get started, start by securing your home Internet connection. This will benefit you and the Internet community in general. I have a page with some information on home broadband security.

When you move to security in a business environment, in my opinion you need to frame security as a tool for risk management. CERT provides good information on handling security professionally, including their book The CERT Guide to System and Network Security Practices and a large collection of Articles, reports and papers.

Information Security Magazine will give you a sense of where the infosec business is going. On the academic side there's the new IEEE Security and Privacy Magazine and the IEEE Computer Society Technical Committee on Security and Privacy. Also on the academic side there are the more established journals from compsec online.

Look. This is a proprietary algorithm which was developed by a non-cryptographer, and which hasn't been peer-reviewed. It is snake-oil until it has been exposed to the light of peer-review.

If you want to meet real NSA cryptographers, you can go to the IEEE Symposium on Security and Privacy, colloquially known as the "Oakland conference" because it's held at the beautiful Claremont resort hotel. Here's a review of last year's conference.

If you want to meet real NSA cryptographers, you can go to the IEEE Symposium on Security and Privacy, colloquially known as the "Oakland conference" because it's held at the beautiful Claremont resort hotel. Here's a review of last year's conference.

No, it's secure because no one has ever found a flaw in tinydns. He has a *cash* reward for anyone who can prove that it is flawed. No one has taken then money, in several years of it being offered.

It's hard to believe that people are still trusting in software security, because no one has won some cracking contest yet. Gene Spafford, Sameer Parekh, Jon Wiederspan, Jeff Weinstein, Bruce Schneier... -- they have been writing about it for decades.

Please let me quote part of The Fallacy of Cracking Contests from the December 1998 issue of Crypto-Gram by Bruce Schneier:

You see them all the time: Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever. These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure.

It doesn't.

Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. (...)

Taken at a conservative $125 an hour for a competent cryptanalyst, a $10K prize pays for two weeks of work, not enough time to even dig through the code. A $100K prize might be worth a look, but reverse-engineering the product is boring and that's still not enough time to do a thorough job. A prize of $1M starts to become interesting, but most companies can't afford to offer that. And the cryptanalyst has no guarantee of getting paid: he may not find anything, he may get beaten to the attack and lose out to someone else, or the company might not even pay. Why should a cryptanalyst donate his time (and good name) to the company's publicity campaign?

Cryptanalysis contests are generally nothing more than a publicity tool. Sponsoring a contest, even a fair one, is no guarantee that people will analyze the target. Surviving a contest is no guarantee that there are no flaws in the target. (...)

Contests, if implemented correctly, can provide useful information and reward particular areas of research. But they are not useful metrics to judge security. I can offer $10K to the first person who successfully breaks into my home and steals a book off my shelf. If no one does so before the contest ends, that doesn't mean my home is secure. Maybe no one with any burgling ability heard about my contest. Maybe they were too busy doing other things. Maybe they weren't able to break into my home, but they figured out how to forge the real-estate title to put the property in their name. Maybe they did break into my home, but took a look around and decided to come back when there was something more valuable than a $10,000 prize at stake. The contest proved nothing.

Bruce Schneier writes mostly about cryptanalysis contests but the situation is basically the same with the software security cracking contests. Let me also quote Hacker Challenges -- Boon or Bane? from the February 1996 issue of Electronic CIPHER. It's almost seven years old, but even today many people still seem to not understand it:

A Few Comments on "Hacker Challenges" by Eugene H. Spafford, COAST Laboratory Director, Purdue University

I note with dismay the increasing number of "hacker challenges" used in marketing security products. I think these are actually harmful to the profession and practice of security, rather than helpful. I believe the harm comes in two ways: (1) the challenges don't serve as any real test of the products, and it denigrates security professionals by suggesting that they should accept them as proof of security; and (2) it helps reinforce the image that there should be some form of reward for hacking through security measures. Neither of these are views we should responsibly seek to promote.

Consider the nature of showing the security of a product. Does a "challenge" meet the goal of testing, which is to increase one's confidence in the correct functioning of the artifact? It really doesn't, for a number of reasons:

• Few such "challenges" are conducted using established testing techniques. They are ad hoc, random tests. Thus, there is no way of determining final coverage. For instance, if 90% of all challenge attacks are of the same variety, what has the "test" really shown? (Consider testing a calculator. If you perform 10,000 tests, but 9000 of them are addition with zero, have you done a thorough job of testing?)
• That no problems are found does not mean that no problems exist. It may mean that the testers didn't expose them. Doing random, black-box testing remotely is not likely to really test much of the product. (Challenge testing is basically a form of black-box testing.)
• That no problems are reported does not mean that no problems exist. The "testers" might not have recognized them. (Look at how often software is released with bugs, even after careful scrutiny -- users don't always recognize anomalies.)
• That no problems are reported does not mean that no problems exist. How do you know that the "testers" will report what they find? How do you know the vendor is getting accurate data? If Jane Random Hacker found a way to penetrate the product in a manner that vendor monitoring didn't expose, it is possible she'd find more profitable uses (later) for that information than informing the vendor about it. Further, because of possible problems with the law, hackers might not want to report success and draw attention to themselves.
• Simply because the vendor does not report a successful penetration does not mean that one did not occur -- the vendor may choose not to report it because it would reflect poorly on its product, or not meet the narrow criteria for a "successful" penetration, or the vendor may not be able to detect it happened. (How can anyone outside prove otherwise?)
• Seldom do the really good experts, on either side of the fence, participate in such exercises. Thus, anything done is usually done by amateurs. (The "honor" of having won the challenge is not sufficient to lure the good ones into the fray. Good consultants command fees of several thousand $$ per day in some cases -- why should they donate their time and names for what amounts to free consulting and advertising?)

So, let me repeat: it is NOT necessarily secure just because no one has ever published a flaw in tinydns (we can't even assume no one has found it). There may be a cash reward for anyone who can prove that it is flawed, but even if no one has proven it yet, it doesn't mean it is not flawed. Remember that it doesn't mean that someone has proven it's secure -- it just means no one has proven it's insecure, which is something totally different. Hopefully, people will understand it some day.

The IEEE Symposium on Security and Privacy is one of the longest-running forums on this topic and is well worth being aware of. The papers for the 2002 session are on CD-ROM; so is a compilation of those from 1980-1999...

However, cutting to the chase, the IEEE and the authors it represents really have little to fear in reality. The IEEE isn't "2600" Magazine; it doesn't deal with controversial subject matter on a regular basis. They aren't in the computer security business and they are unlikely to accept any remotely controversial manuscript in the first place. They changed their rules for one simple reason: they think it will make people care about the injustices of the law.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

However, cutting to the chase, the IEEE and the authors it represents really have little to fear in reality. The IEEE isn't "2600" Magazine; it doesn't deal with controversial subject matter on a regular basis. They aren't in the computer security business and they are unlikely to accept any remotely controversial manuscript in the first place. They changed their rules for one simple reason: they think it will make people care about the injustices of the law.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

• At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
• Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
• At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.

There was a report in 1996 that said that 65% of in-house testing hacks were successful. According to this more recent article, 3% of attempts caused damage, and only 1% managed to break into unclassified systems. That's a good sign, I think. Hacks are increasing at 10% a year, and security is increasing faster.

The Pentagon is trying to protect itself from future attacks by deciding to "to carefully consider the origin of all software used in developing or upgrading information technology or national security systems." It sounds like they're mostly worried about those "foreigners" trying to put in backdoors. I'm not sure why they trust Americans more. But by using commercial software, like Microsoft and Lotus Notes, they're not only making their task impossible (anyone want to parse Win2000 to figure out which parts were written where?), but are focusing on the wrong worries. They should use smaller software packages, that can actually be reviewed, instead of huge bloatware that permits backdoors to be hidden.

Thalia