Slashdot Mirror

There is a fundamental problem in the idea for this "revamped slashdot".
The idea of making the site more inclusive and appealing to a wider "audience" by changing how the looks and works is a bad idea. /. is a community. If you want growth for the site, you don't water down your site and do things that upset the community. You make get to know the members of your community and make sure they are happy with the site and properly engaged. You address the needs of the community and allow its members to spread the word.

Those now running this site do not understand the community. If they did, they wouldn't be doing this awful redesign. They would be looking at improving the site as it exist. They would be curating stories that are NOT glorified press releases or PR stunts. They would be looking for stories that fit the theme of "Slashdot: News for nerds, stuff that matters." They would be seeking out ads and ad partners that would respect the community with non-invasive non-tracking relevant ads.

The fact they had to post and that this thread has to exist is testament to how far out of touch with the community they are.

I'm sure someone somewhere decided that /. was under-preforming* and thought "I know lets re-brand it for the people we want to use it." No where was there thought about the people currently using it except the assumption current users would simply go along with it. At most they probably (possibly rightly so, only time will tell) assumed that people would bitch and moan but in the end stick with the site either out of habit or ignorance. The people in charge don't care about us and will happily play chicken to see if anyone sticks around. Besides, the managers responsible for this fiasco will be moved on to other jobs before any real fall out.

What we should be doing is making our voices heard to any person or company that advertises on any DICE site. Let their advertisers know they don't care about the people and that we won't buy products from people who support Dice Holdings, Inc. or any of their subsidiaries or affiliates.

*from Dice Inc.
"Slashdot Media was acquired to provide content and services that are important to technology professionals in their everyday work lives and to leverage that reach into the global technology community benefiting user engagement on the Dice.com site. The expected benefits have started to be realized at Dice.com. However, advertising revenue has declined over the past year and there is no improvement expected in the future financial performance of Slashdot Media's underlying advertising business. Therefore, $7.2 million of intangible assets and $6.3 million of goodwill related to Slashdot Media were reduced to zero. "

Also if you were curious why the redesign looks like it does, check out the other dice sites. It appears they are going for a bland unified style across sites. http://news.dice.com/ is especially telling of what the future of /. may hold.

Side note:
I was curious who this timothy guy was, so I clicked his name up there. Brought me to: http://www.monkey.org/~timothy...
If that is his personal site, how in the world should this person be allowed anywhere near the design of /.

Agreed that blog post is bereft of data explaining the conclusions reached in TFA, but it appears that the "Craig" who penned the post is this guy, Dr. Craig Labovitz

Send comments and requests to timothy. Commenting on slashdot will fall on blind eyes.

The main point is performance. Ryan Dahl wanted to write fast, scalable servers easily. We all know for years that threads don't scale but event loops do (see the second chart of memory consumption of apache vs nginx). Of course in order to have a highly concurrent evented server you can't use blocking system calls (which were a big mistake in my opinion to begin with - they are the only reason why you needed threads exposed at the application level for concurrency in the past). OK, so we want a portable, high performance, event-based, async-I/O, scalable, highly concurrent server. The obvious way to write such servers in a portable, OS-independent way was to write them in C using libraries like libev or libevent for event loops and libeio for non-blocking I/O. The result is great. But the problem is that it is not easy. C doesn't have lambdas, anonymous functions, closures or higher-order functions in a real sense, which all would make writing event handlers much easier. So Ryan was looking for a higher level language and found V8, the JavaScript virtual machine written by Google for Chrome. JavaScript has anonymous functions and closures. And V8 is fast. And also when you write JavaScript in the browser then you never use blocking function calls anyway, so people are already familiar with asynchronous I/O, events, callbacks, closures, futures and promises. Hell, you can even use Y combinators in JavaScript if you know your craft. Now, if only JavaScript had lazy evaluation and proper tail call optimization - maybe some day. Watch some talks by Ryan Dahl if you're interested and after 25 years in the field you should be. Oh, and Node doesn't have anything to do with the browser besides the V8 origins. It's all server-side. See the Wikipedia article on Node for more info and code examples. I'm glad that people who have been professionally programing for so many years are still willing to broaden their horizons. As I have written in the past it is not a universal property of programmers unfortunately. Have fun with new tools.

http://monkey.org/~dugsong/dsniff/faq.html#How%20do%20I%20sniff%20/%20hijack%20HTTPS%20/%20SSH%20connections

However, it will be difficult for Internet policymakers, engineers and the user community at large to tell how the upgrade to IPv6 is progressing because no one has accurate or comprehensive statistics about how much Internet traffic is IPv6 versus IPv4."

I'm sorry, but that's utterly wrong. There are people who are watching this stuff. One of them is Craig Labovitz, Chief Scientist at Arbor Networks. He authored a paper six months ago called Six Months, Six Providers, and IPv6. In it, he says that tunneled IPv6 accounts for between 0.01% and 0.05% of all Internet traffic while IPv6 on providers which support it natively accounts for about 0.1% of all traffic. I'm willing to bet that he and/or Arbor will have some news about IPv6 traffic levels on IPv6 day.

If you scroll down a bit, you'll also see that P2P amounts to the majority (61%) of v6 traffic. I also find it fascinating that SSH and Web traffic both account for 4.6% of v6 right now.

And in just 6 months, we'll all be celebrating the 15th anniversary of the first official release of OpenBSD.

dsniff was released over 10 years ago and does what you suggest. OpenSSH still works fine using the equivalent of self-signed certificates.

A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates? On every connection their customers make?

I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections. What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of? So what if StartSSL assures me it's run by someone called Joe Bloggs, why do I care? What security does it buy me over and above a self-signed certificate? How about compared to the self-signed certificate my browser stored when I initially signed up to Joe Bloggs' forum?

Here in the US, surveillance is privatized. The article won't load because we have "google-analytics.com" blocked. Page load is stalled here:

<script type="text/javascript">

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-20036650-1']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

Big Google is watching you. And you can't turn him off.

Arbor Networks has been providing some really good graphs detailing typical usage and sudden drops of internet traffic.

You're right. I assumed that most DDoS attacks used large botnets, but read this: http://www.monkey.org/~labovit/nanog50.pdf and learned otherwise. It does seem like there just aren't good statistics on what the distribution of such attacks is.

Probably 95 percent of THOSE networks were defeated using Doug Song's tools.


http://monkey.org/~dugsong/dsniff/

Does Timothy even glance at the stories he approves or is it pure pin the tail on the donkey?

Timothy's e-mail address is timothy@monkey.org according to his home page. Tired of the half-assed submissions where he couldn't bother to read it over before submitting it for millions to read? Send him an e-mail.

really, thats insightful? A simple, two sentence answer with about as much insight as a Family Circle (Now Family Circle is funny, sometimes clever, but rarely insightful) comic strip. here is a link to the Dictionary.com entry for insight. how in the heck can this be called insightful in any capacity and especially since timothy seems like he wants to avoid litigation. you reh-tarts with your mod points, who are in effect responsible for what people will look at on this site, should consider more wisely where you spend your points.

And, timothy, just sue. Its the only way to get shit done anymore. that or war. Also BoingBoing took the image down, so posting on /. may be a new viable alternative.

But software which OpenBSD uses and redistributes must be free to all (be they people or companies) for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.

--Theo de Raadt

http://www.monkey.org/openbsd/archive/source-changes/0105/msg01243.html

Free means free, not "free only if I approve of what you do/look like/think/etc.

It's kinda silly having a packet sniffer listening to all passing traffic, when all they really needed to do was look in common places for stored passwords, and have a keystroke logger intercept interesting things.

That was my initial reaction. Then I started really thinking about it.

It's probably harder to determine when those "interesting things" are, and even harder to programatically extract the really useful information from the keystroke logger. However protocol analyzer code already exists, and can detect usernames and passwords without human intervention. This means that the entire attack can be automated, from credential stealing to defacement.

That's not to say that keystroke loggers are going to go away any time soon, but I suspect that for now, they still require human intervention to detect the really useful bits (or at least to do so with a high degree of accuracy.)

The website listed in the post has a fine example of a simple top level domain presence: http://www.monkey.org/

Yes and /dev/poll on Solaris and kqueue on FreeBSD or just do the best thing on whatever your system is by using libevent:

http://www.monkey.org/~provos/libevent/

Poll is sadly O(N) but there are some optimizations that can be made to poll to make it faster.

First poll does not need to be a simple syscall that copies over the entire array into kernel memory. Almost every time that poll is called that array is identical to what it was the last time and at the same address. libc can in userspace first compare that array, base addr, and size and when all is the same it can call a faster poll syscall or pass an arg to tell it to do the fast path of what was done the last time.

Secondly the kernel does not need to copy a buffer for the results into the userspace. It can simply just twiddle that memory itself while still in the kernel context.

Finally there can be optimizations for the simple typical case of there only being a few descriptors, like 8 or less.

Many systems do some or all of those, from performance measurements it seems to me that Solaris does particularly well.

Good thing this one didn't involve any numbers - saved T from another embarrassing user-prodded edit.

> "Update: 03/12 18:42 GMT by T : The original story incorrectly said the ISS had 18 crew members. Luckily for the three in the Soyuz, that was a mistake."

Hey, T, the three already in the Soyuz would be protected, right? Regardless of how many more there may or may not have been... They don't need luck.

Makes no sense ya mah'rune.

> "Update: 03/12 18:42 GMT by T : The original story incorrectly said the ISS had 18 crew members. Luckily for the three in the Soyuz, that was a mistake."

Hey, T, the three already in the Soyuz would be protected, right? Regardless of how many more there may or may not have been... They don't need luck.

Makes no sense ya mah'rune.

sslsniff v0.5 : http://www.thoughtcrime.org/software/sslsniff/
dsniff (sshmitm) : http://www.monkey.org/~dugsong/dsniff/
ettercap : http://ettercap.sourceforge.net/

Nothing's secure.

I'm not exactly a security expert, but how is this different from regular HTTPS hijacking? Specifically this seems to be the same as what I read in the dsniff FAQ years ago. It was written in 2001. I'm apparently missing something.

Dear Timothy:

Please don't use Slippery and Porn in a headline together. Ohhh, my head, it burns!

I somehow doubt they were involved since they went out of business six months ago.

What?! You mean Ceren doesn't work there any more?

No, not for a while, actually.

http://www.monkey.org/~dugsong/dsniff/faq.html

Section 3.4, and I quote

Although HTTPS and SSH are encrypted, they both rely on weakly bound public key certificates to identify servers and to establish security contexts for symmetric encryption. As the vast majority of users fail to comprehend the obtuse digital trust management PKI presents (e.g. is an X.509v3 DN really meaningful to you?), a simple monkey-in-the-middle attack works quite well in practice.

Client traffic to a target server may be intercepted using dnsspoof and relayed to its intended destination using the sshmitm and webmitm proxies (which also happen to grep passwords in transit). For example, to sniff Hotmail webmail passwords, create a dnsspoof hosts file such as:

1.2.3.4 *.passport.com
1.2.3.4 *.hotmail.com

where 1.2.3.4 is the IP address of your attacking machine. Local clients attempting to connect to Hotmail will be sent to your machine instead, where webmitm will present them with a self-signed certificate (with the appropriate X.509v3 distinguished name), and relay their sniffed traffic to the real Hotmail site.

sshmitm is perhaps most effective at conference terminal rooms or webcafes as most travelling SSH users don't carry their server's key fingerprint around with them (only presented by the OpenSSH client, anyhow). Even sophisticated SSH users who insist on one-time passwords (e.g. S/Key), RSA authentication, etc. are still at risk, as sshmitm supports monitoring and hijacking of interactive sessions with its -I flag.

The reporter that exposed the problem should not be booted from future conferences, he should be welcomed back!

Dug Song wrote dsniff in 2000 - it's not news that you can see passwords go past on switched ethernet.

So run your BitTorrent client under trickle. You can tell either trickle or trickled what the maximum rates are, and the configuration file allows control based upon the name of the application; the app can use whatever port and encryption it wants, as trickle controls it at its own network interface. No guessing by the kernel what application is involved.

Granted, this'd work for most "average" computer users accustomed to clicking "OK" every few minutes. But if you're the sort of person who uses TOR, surely a bogus SSL cert would be enough to set of plenty of alarm bells. heck, I remember logging into my newly built file server at home an noticing that the SSH key had changed - cue immediate power down, reformat and analysis of all other boxes I had access to before I realised that the account I was using at the time was using ~/.ssh that hadn't been touched for at least a year (with the previous incarnation of that server still in known_hosts). D'oh!

Anyway, in answer to the GP, a bit of googling found (amongst other things) this: http://www.monkey.org/~dugsong/dsniff/ which I shall give a whirl tonight...

Since multithreading is a real requirement for performance and scalability these days, (threads scale for performance better than processes, and you can always have more processes too)

No! General multithreading is not the solution for extreme performance, especially on web applications. Multithreaded applications have too many locks and context-switching. You want something like a libevent driver or Python Twisted that does single-threaded event dispatching with asynchronous I/O, so you can avoid locking and context switches.

What's more, thread concurrency is really a red herring here. You only want enough threads to keep a single CPU busy without thrashing... server farms get more concurrency simply by adding CPUs, and that is far more effective than throwing 10,000 threads onto a single server (take Google, for example). If you're writing multithreaded PHP scripts that are accessed from the web, I am sorry for whoever has to come maintain it. Much cleaner to multithread by using object, iframe, or other client-side methods of invoking multiple server-side scripts concurrently.

Assuming what you would do is sniffing as opposed to a man in the middle attack. A lot of work has gone into encryption but people seem to forget about the other peices of the puzzle. Where are those DNS packets coming from? Do you accept ICMP redirects? Is your gateway really a router?

http://monkey.org/~dugsong/dsniff/faq.html

see section on "how do I hijack/sniff https connections?".

Dsniff / Monkey in the middle attacks

To me it sounds more like dsniff http://monkey.org/~dugsong/dsniff/, capturing only passwords, usernames, that kind of stuff.

But it is the OS for baby mulching machines

Leave it to google to make their software unfree by going with the Apache 2.0 license.

Fuck forgot the link...here it is: http://www.monkey.org/~jose/tmp/GriefBomb1.jpg

It turned out it was another admin, who had gone some kind of crazy. He had three NICs in his desktop box all configured to impersonate different machines, he had re-routed the boss's email through his mailbox (and some clients' mail too), and had all kinds of other things going on.

Good thing he was fired, because dsniff is the appropriate suite of tools for reading other people's network traffic. Duh!

The excellent network attack package dsniff has a really cool utility tcpnice that may help.

The whole thing reminds me of how I felt in my first couple of months using linux, when I really, really wanted Linux versions of GetRight and ZoneAlarm. Shows how much I knew then, really.

Sniff on a switch with DSNIFF.

but I typically only ANAL once a month or so. Like many of you, especially slashdot subscribers, I'd love to ANAL every day if I could. So how about it, slash-holes, how about giving some love and giving up the anal to a fellow slashdotter.

Thanks in advance.

Tim
timothy@monkey.org

I hope timothy creates a backslash article on /. for this one! So we can talk about it twice!

Legit question ... Just curious when and how did this backslash stuff begin? It appears it was timothy's creation?

Looks like the solution is to fold up a piece of paper

It's not quite that simple.

The article is inaccurate. It says you you can fold an origami star or merely just fold the paper in a square. Neither of these methods will work. Instead, fold the origami (or other, but origami paper is preferred) into a crane, as shown here. Then smash the origami crane with your fist, using a quick up and down motion, as if you were masturbating.

From here, follow the rest of the directions in the article, and your trackpad should soon be clicking like there's no tomorrow.

On a side note, does anyone know of a PDF viewer program that ignores the "No Print / No Copy" restrictions?

Yes indeed, there're several!

I had a heck of a time figuring out what the problem was with sound on my Thinkpad 390X in OpenBSD. I know it's probably not the same in Linux, but maybe it'll point you in the right direction:

Sound on a Thinkpad in OpenBSD

But it looks like there may be something real here.

The presentation lists events that will trigger a System Management Interrupt (SMI) and enter System Management Mode (SMM). Overheating is only one of them. Another is "century rollover". Taken literally, that would mean that anyone who could set the clock to 11:59 December 31 1999 [I'd say 2000 but I doubt the chip is mathematically correct] can enter SMM without needing physical access to the machine or to the circuit breaker for the air conditioning. Or to use the presentation's example, outl(0xB2, 0x0000000F);.

If I read this problem report correctly, then a process outside of SMM can write to the memory for SMM. (Controlled by the D_OPEN bit in the SMM control register).

So it looks like you can do it without physical access, where "it" is a privilege escalation that *starts* from root. That's getting less absurd all the time as virtualization and technologies like SELinux become more common. Also allows planting a deeper-than-root rootkit. You could escalate to God of Hardware or in the CanSecWest example to "root at securelevel -1".

Maybe I should email Duflot for details and write up something for my nerdish security blog

While DJB has interesting ideas sometimes, his software are not open source, and he's stuck with his ideas.
Even if his software are in general of good quality, they have the same problems as other proprietary software and don't get integrated very well into the system.

Look at this thread on the openbsd mailling list :
http://www.monkey.org/openbsd/archive/ports/0109/m sg00025.html

What tools and methods are the best practice when trying to use Linux and Open Source to analyze and fix a network?

• Nagios
• Snort
• ethereal
• dsniff (not updated in ages)
• ncat
• nmap
• nessus v 2 (or one of the forks of version 3)
• SARA

in 2002, a series of high profile compromises of internet software servers resulted in the alteration of software archives. this prompted an evaluation of the state of trust of the signed software distribution system. over 2800 archives representing over 1400 unique software packages were downloaded and their corresponding signatures evaluated for validity. these software packages were pulled from over 260 different sites and the keys retrieved only during the verification stage. of the over 2800 archives checked, only 5 errors were found, three of which were found to be false negatives. additionally, the characteristics of the keys used to sign these archives along with the key distribution systems were studied. these findings highlight weaknesses in the signed archive distribution system and demonstrate clear vulnerabilities facing several projects.