This kind of brute-forcing is common. The simplest way to deal with it is to set up SSH public key authentication, disable SSH password authentication, and forget about it.
One method I use to assess software quality is to skim through the source code. If the source is clean, organized, elegant, and well thought out, I have greater confidence. If the source is sloppy, uses inconsistent indentation/spacing, and is generally a mess, then it's obvious the author(s) lacked attention to detail and didn't put much care into it.
This doesn't fully answer the question—notably, clean-looking code can still contain bugs—but it can yield surprising insight in a short time.
After all, security is part of correctness, which in turn is part of building software with ability and care.
So, first we made the atmosphere off-kilter, and now we're going to fix it by unbalancing the oceans too?
The proposal appears to work by making the oceans absorb the extra CO2, like a giant sponge—because after causing problems in the air all this CO2 will somehow be fine in water. Adding a zillion tonnes of CO2 to the air worked so well that we'll put it in the water too, plus a zillion tonnes of lime. What could possibly go wrong?
Meanwhile, CO2 production continues unabated.
Maybe later, once the air and water are both full of CO2, we'll find a way to put it into the earth too.
Marcus Ranum has an interesting talk (MP3) in which he discusses Feynman's Challenger commentary at some length in the context of designing reliable/secure software systems.
The talk gets off to a bit of a rough start (see Ranum's comment below), but contains much insight and makes a lot of sense before long. Highly recommended for those in the software development field, where the approach is often 'throw it together, then poke at it and patch it until it stops obviously breaking'; the rigour Feynman & Ranum describe may be overkill for some systems, but exposure to this other approach can help make most of us better developers. I found it helpful, anyway—your mileage may vary.
This was an improvised dinner address, delivered without powerpoints and after a few too many bottles of beer. [...] The objective of this talk was to take the high ground with respect to treating computing as an engineering discipline, instead of the kettle of kludges that it has become. I realize it's very very idealistic stuff.
Oops, one correction: spamd is not actually an SMTP proxy. Rather, the firewall takes care of directing the sender's TCP packets to either (a) spamd or (b) the real MTA, as appropriate. Spamd, meanwhile, updates a firewall state table on the fly; for example, spamd may determine that a particular sender is legitimate, then update the firewall state table such that the sender's next mail delivery attempt goes to the real MTA, not to spamd again. Sorry for the mixup.
This is clever: filtering spam by exploiting properties of spam pumps in general, vs. straight content analysis. The competition of ever-more-sophisticated content scanning techniques on one side, and spammers' escalating workarounds and huge botnets on the other side, is an arms race that shows no sign of abating.
Of course, this approach does still depend on something—probably content analysis—to determine which messages are spam and which are not, so that receivers' spam statistics can be computed.
The smartest (and reportedly most effective) anti-spam technique I know is spamd, which completely sidesteps content analysis. In a nutshell, it's an SMTP proxy that issues a temporary error code to unknown senders; legitimate MTAs retry delivery (at which point spamd lets the message through), while spam pumps don't bother. Voilà—spam gets stopped before it's ever received. A friend of mine reports that spam volume has dropped to zero since he set up spamd for his department.
If I understand the "receiver reputation" approach correctly, it could use spamd (rather than content analysis) to identify spam; similarly, content analysis can supplement spamd. The two are potentially complementary.
Although this is obvious to many—if you're transmitting data unencrypted from A to B, someone monitoring the communication channel can of course read the data too—the reality is that it probably takes a concrete, real-world package like this, plus media coverage, to before many organizations will grasp the risk.
In other words, although much of the slashdot crowd will say "well, duh", this is a very practical wake-up call for real-world organizations that have deployed VoIP. Of course they'll need to either use encryption of trust everyone and all machines on the network.
Coming up next: An attacker with appropriate radio gear can eavesdrop on cell phone conversations!
The full quote is: "Furthermore, Yahoo Hong Kong's legal registration is not in [mainland] China; it has no obligation at all to follow mainland China's law."
It seems his point is that Yahoo's Hong Kong branch provided the information, but that branch is a legal entity incorporated in Hong Kong, and is therefore outside the jurisdiction of mainland Chinese laws (Hong Kong laws apply instead). Similarly, if police in North Korea or Cuba or Vietnam were to ask Yahoo's U.S. headquarters for information, they would have no jurisdiction and Yahoo would have no legal obligation to comply.
If it were a Yahoo branch incorporated in mainland China that had provided the information, your point would be quite valid.
I am not a lawyer, and I have not studied the relevant legalities; this is just my understanding of the statement you referred to.
(Of course, the purpose of the law is to uphold justice anyway, and from that perspective things are perhaps a bit more clear.)
Yahoo has often recited the standard 'must comply with local laws' line, but have they ever identified which Chinese law(s), specifically, forced their hand? They were even asked point-blank, and remained conveniently silent.
Shi Tao's lawyer says there was "no obligation at all to follow mainland China's law" (from the article linked above).
Is there in fact any substance to Yahoo's position, or is it just a hollow public relations exercise? If there's truth to what Yahoo says, they could be a bit more open about this.
... is that Chavez has now threatened to block the Internet. This news comes via email from Venezuelan students who are protesting the silencing of RCTV. It's not easy to confirm this either way, but readers can draw their own conclusions.
There is reportedly now only one small Venezuelan media outlet remaining that's "said to be still willing to report honestly on events in Venezuela", and Chavez has apparently threatened to shut it down too.
Students protesting RCTV's shutdown also report that security forces went out of their way to kill one of the protesters. True or false? Again, hard to say for sure, but either way you can bet that most Venezuelan media won't report it.
There's an informative message from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:
Noone in OpenBSD is pissed off about this. We posted the bug fix as
soon as we became aware of the problem. The timeline goes like this:
1) We were told there was a mbuf crash, which could remotely CRASH
the machine. There was no proof that more could be done, not even
a whiff.
2) We commited the fix, about 24 hours later. It took a few days to
get the errata up because the people who do that were at a conference.
It was labelled as a RELIABILITY FIX because everyone felt it was just
a CRASH. I then entered into a long conversation with Core explaining
why we label crash fixes (even remote) as RELIABILITY FIXES.
3) Core felt maybe something more could be done and continued working,
and ONE WEEK LATER later, finally managed to show us brand new code
which showed that intrusion was possible. Before that moment, it
was still just confirmed to be a CRASH.
4) A few hours after we become aware that it was more than a CRASH, we
changed the advisory to say it was a real security risk. We first had
to get the patch into -stable,
I changed index.html to talk about there being TWO remote holes in
more than 10 years, without even discussing this with any other
developer, because I knew it was true. Other developers in the group
were stunned to see me change it.
5) Core decided that their advisory should include their interpretation
of our discussion as to why OpenBSD labels crash fixes as RELIABILITY
FIXES. Three times I told them that I thought that was a mistake,
and that the public would not understand the reasoning as they wrote
it.
That is what happened. If you don't believe me, mail Ivan Arce at
Core and ask him if any of the 5 points above are wrong. Come on, go
ask him if I am a liar... go ahead.
Yes, some of the press got it wrong too, and part of that I feel is
Ivan Arce's fault. He should have been more cautious at explaining
the complex discussion OpenBSD had with Core, where we explained why
we label errata for remote crashes a Reliability Fix. Or he should
have skipped it altogether.
He even went around telling the press that this shows that IPV6 is a
risky new technology, when the fact is that this was a mbuf corruption
bug, in code that all parts of the network stack could potentially use
in the same way. He's got his layers wrong. But finding bugs in
other people's software lets companies like Core sell themselves as
experts. They are experts, but the good press they get should not
cost us in this way.
Core Security certainly deserves credit for finding this. Their advisory and de Raadt's timeline, however, give rather different impressions. Perhaps reading both will give a more complete picture.
When I had a similar problem several years ago, I simply switched to using the mouse with my left hand to give the right a break. It worked.
High-tech gadgetry may help, but the human factors are key; for example, even the best ergonomic devices won't prevent damage if one's technique is poor.
The thumb is an odd place to have pain when using a mouse, which suggests that there's something happening here that replacing the mouse will not correct. Maybe ensure that the posture, workspace, and keyboard/mouse technique are ergonomically sound (well, as sound as such unnatural activity can be).
The joke in on tech support in the end in this one, from my first job. George received the call, which went something like this:
Customer: Hello, I'm calling because your CD-ROM makes a buzzing noise during installation.
George: Pardon me, sir—a buzzing noize?
Customer: Yes, it vibrates, making a kind of loud buzzing noise.
George: Are there any errors?
Customer: No, the installation works just fine.
George: And the software works correctly?
Customer: Yes, no problem. But the CD makes a buzzing noise.
George (becoming creative): Hmm... well, sir, there's a lot of information on that CD, and it could be that there's more information on one side of the disc than the other. If it's weighted unevenly, this could make it wobble as it spins, causing it to buzz.
Customer: Oh, that makes sense. Well, no big deal, I guess. Thank you.
It turns out that many other customers called with the same complaint; there was indeed a manufacturing defect with a batch of CDs.
Yahoo was asked directly which specific law they were following. They didn't answer.
The purpose of the law is to uphold justice, but some "laws" are created specifically to maintain the communists' dictatorship. There is always an element of choice.
So, when we say that Western companies must follow the law if they are to operate in China, this isn't the same as doing whatever Beijing demands. The cadres in Beijing are also adept at enticing Western companies to toe the party line willingly.
These companies know this when they enter the Chinese market. They cannot accept only the financial profit but none of the responsibility for the consequences of their actions.
... that Google doesn't voluntarily identify users who do this, like Yahoo did.
Unfortunately, many high-tech companies are all to eager to do business with a regime that has killed 80 million people. Western companies' equipment, software, and expertise are what allow China's 30,000+ full-time internet censors to block this kind of breakthrough soon after they're discovered. They couldn't have built such a system without our help.
It's an interesting place indeed... built in the Cold War under Prime Minister Diefenbaker (hence the name Diefenbunker).
From the outside, it looks like an unassuming shed, but inside is a blast tunnel that leads into the hillside and down to a four-storey complex beneath. First stop: the radiation decontamination chambers. Last stop: the gift shop, which offers official Cold War-era federal government publications—in English and French—about how to build a bomb shelter at home. Along the way are a room where federal leaders would meet, a room for the Prime Minister (cot-sized only—no spuose allowed), a room for the Governor General, backup headquarters of the Canadian Broadcasting Corporation, a sizeable cafeteria, bunk beds (each shared by three people in eight-hour shifts), a filtration system for extracting radioactive particles from surface air, etc.. The transmitters are located something like 14 kilometres away to prevent locating the bunker through triangulation.
At the lowest level is the Bank of Canada vault that would store gold in the event of a disaster (radioactive gold is not so valuable); it has the biggest vault door I've ever seen, and has a rectangular hallway around it with a mirror in each corner so a guard standing in one place could see all the way around.
I always liked Slow Wave... they're all write-ups of people's dreams. It's interesting—and often hilarious—to see the oddities that pass through people's minds while they sleep.
Slashdot Mirror
This kind of brute-forcing is common. The simplest way to deal with it is to set up SSH public key authentication, disable SSH password authentication, and forget about it.
One method I use to assess software quality is to skim through the source code. If the source is clean, organized, elegant, and well thought out, I have greater confidence. If the source is sloppy, uses inconsistent indentation/spacing, and is generally a mess, then it's obvious the author(s) lacked attention to detail and didn't put much care into it.
This doesn't fully answer the question—notably, clean-looking code can still contain bugs—but it can yield surprising insight in a short time.
After all, security is part of correctness, which in turn is part of building software with ability and care.
So, first we made the atmosphere off-kilter, and now we're going to fix it by unbalancing the oceans too?
The proposal appears to work by making the oceans absorb the extra CO2, like a giant sponge—because after causing problems in the air all this CO2 will somehow be fine in water. Adding a zillion tonnes of CO2 to the air worked so well that we'll put it in the water too, plus a zillion tonnes of lime. What could possibly go wrong?
Meanwhile, CO2 production continues unabated.
Maybe later, once the air and water are both full of CO2, we'll find a way to put it into the earth too.
Marcus Ranum has an interesting talk (MP3) in which he discusses Feynman's Challenger commentary at some length in the context of designing reliable/secure software systems.
The talk gets off to a bit of a rough start (see Ranum's comment below), but contains much insight and makes a lot of sense before long. Highly recommended for those in the software development field, where the approach is often 'throw it together, then poke at it and patch it until it stops obviously breaking'; the rigour Feynman & Ranum describe may be overkill for some systems, but exposure to this other approach can help make most of us better developers. I found it helpful, anyway—your mileage may vary.
Oops, one correction: spamd is not actually an SMTP proxy. Rather, the firewall takes care of directing the sender's TCP packets to either (a) spamd or (b) the real MTA, as appropriate. Spamd, meanwhile, updates a firewall state table on the fly; for example, spamd may determine that a particular sender is legitimate, then update the firewall state table such that the sender's next mail delivery attempt goes to the real MTA, not to spamd again. Sorry for the mixup.
This is clever: filtering spam by exploiting properties of spam pumps in general, vs. straight content analysis. The competition of ever-more-sophisticated content scanning techniques on one side, and spammers' escalating workarounds and huge botnets on the other side, is an arms race that shows no sign of abating.
Of course, this approach does still depend on something—probably content analysis—to determine which messages are spam and which are not, so that receivers' spam statistics can be computed.
The smartest (and reportedly most effective) anti-spam technique I know is spamd, which completely sidesteps content analysis. In a nutshell, it's an SMTP proxy that issues a temporary error code to unknown senders; legitimate MTAs retry delivery (at which point spamd lets the message through), while spam pumps don't bother. Voilà—spam gets stopped before it's ever received. A friend of mine reports that spam volume has dropped to zero since he set up spamd for his department.
If I understand the "receiver reputation" approach correctly, it could use spamd (rather than content analysis) to identify spam; similarly, content analysis can supplement spamd. The two are potentially complementary.
Although this is obvious to many—if you're transmitting data unencrypted from A to B, someone monitoring the communication channel can of course read the data too—the reality is that it probably takes a concrete, real-world package like this, plus media coverage, to before many organizations will grasp the risk.
In other words, although much of the slashdot crowd will say "well, duh", this is a very practical wake-up call for real-world organizations that have deployed VoIP. Of course they'll need to either use encryption of trust everyone and all machines on the network.
Coming up next: An attacker with appropriate radio gear can eavesdrop on cell phone conversations!
There's a study from the universities of Harvard, Toronto, and Cambridge that gives some insight into which topics the legions of censors put the most energy into blocking.
Biggest surprises:
Biggest lack of surprise: Sites related to the Tiananmen massacre and Falun Gong were thoroughly blocked.
This gives a sense of what the regime there is most afraid of people reading.
I suggest that Chinese readers find a proxy and read up on exactly these topics.
The full quote is: "Furthermore, Yahoo Hong Kong's legal registration is not in [mainland] China; it has no obligation at all to follow mainland China's law."
It seems his point is that Yahoo's Hong Kong branch provided the information, but that branch is a legal entity incorporated in Hong Kong, and is therefore outside the jurisdiction of mainland Chinese laws (Hong Kong laws apply instead). Similarly, if police in North Korea or Cuba or Vietnam were to ask Yahoo's U.S. headquarters for information, they would have no jurisdiction and Yahoo would have no legal obligation to comply.
If it were a Yahoo branch incorporated in mainland China that had provided the information, your point would be quite valid.
I am not a lawyer, and I have not studied the relevant legalities; this is just my understanding of the statement you referred to.
(Of course, the purpose of the law is to uphold justice anyway, and from that perspective things are perhaps a bit more clear.)
Yahoo has often recited the standard 'must comply with local laws' line, but have they ever identified which Chinese law(s), specifically, forced their hand? They were even asked point-blank, and remained conveniently silent.
Shi Tao's lawyer says there was "no obligation at all to follow mainland China's law" (from the article linked above).
Is there in fact any substance to Yahoo's position, or is it just a hollow public relations exercise? If there's truth to what Yahoo says, they could be a bit more open about this.
There is reportedly now only one small Venezuelan media outlet remaining that's "said to be still willing to report honestly on events in Venezuela", and Chavez has apparently threatened to shut it down too.
Students protesting RCTV's shutdown also report that security forces went out of their way to kill one of the protesters. True or false? Again, hard to say for sure, but either way you can bet that most Venezuelan media won't report it.
The patch was released on April 27. Now that's quick!
The OpenBSD project does a great job with security; other development teams could learn a lot from them.
There are flavours for OpenBSD, FreeBSD, and NetBSD. Here's a handy introduction.
There's an informative message from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:
Core Security certainly deserves credit for finding this. Their advisory and de Raadt's timeline, however, give rather different impressions. Perhaps reading both will give a more complete picture.
When I had a similar problem several years ago, I simply switched to using the mouse with my left hand to give the right a break. It worked.
High-tech gadgetry may help, but the human factors are key; for example, even the best ergonomic devices won't prevent damage if one's technique is poor.
The thumb is an odd place to have pain when using a mouse, which suggests that there's something happening here that replacing the mouse will not correct. Maybe ensure that the posture, workspace, and keyboard/mouse technique are ergonomically sound (well, as sound as such unnatural activity can be).
The joke in on tech support in the end in this one, from my first job. George received the call, which went something like this:
Customer: Hello, I'm calling because your CD-ROM makes a buzzing noise during installation.
George: Pardon me, sir—a buzzing noize?
Customer: Yes, it vibrates, making a kind of loud buzzing noise.
George: Are there any errors?
Customer: No, the installation works just fine.
George: And the software works correctly?
Customer: Yes, no problem. But the CD makes a buzzing noise.
George (becoming creative): Hmm... well, sir, there's a lot of information on that CD, and it could be that there's more information on one side of the disc than the other. If it's weighted unevenly, this could make it wobble as it spins, causing it to buzz.
Customer: Oh, that makes sense. Well, no big deal, I guess. Thank you.
It turns out that many other customers called with the same complaint; there was indeed a manufacturing defect with a batch of CDs.
Yahoo insists that it does this only when "legally compelled" to do so. With Shi Tao, though—and perhaps with Li Zhi as well—the request from mainland China simply held no weight in Hong Kong, which is where Yahoo was registered.
Yahoo was asked directly which specific law they were following. They didn't answer.
The purpose of the law is to uphold justice, but some "laws" are created specifically to maintain the communists' dictatorship. There is always an element of choice.
So, when we say that Western companies must follow the law if they are to operate in China, this isn't the same as doing whatever Beijing demands. The cadres in Beijing are also adept at enticing Western companies to toe the party line willingly.
These companies know this when they enter the Chinese market. They cannot accept only the financial profit but none of the responsibility for the consequences of their actions.
Unfortunately, many high-tech companies are all to eager to do business with a regime that has killed 80 million people. Western companies' equipment, software, and expertise are what allow China's 30,000+ full-time internet censors to block this kind of breakthrough soon after they're discovered. They couldn't have built such a system without our help.
It's an interesting place indeed... built in the Cold War under Prime Minister Diefenbaker (hence the name Diefenbunker).
From the outside, it looks like an unassuming shed, but inside is a blast tunnel that leads into the hillside and down to a four-storey complex beneath. First stop: the radiation decontamination chambers. Last stop: the gift shop, which offers official Cold War-era federal government publications—in English and French—about how to build a bomb shelter at home. Along the way are a room where federal leaders would meet, a room for the Prime Minister (cot-sized only—no spuose allowed), a room for the Governor General, backup headquarters of the Canadian Broadcasting Corporation, a sizeable cafeteria, bunk beds (each shared by three people in eight-hour shifts), a filtration system for extracting radioactive particles from surface air, etc.. The transmitters are located something like 14 kilometres away to prevent locating the bunker through triangulation.
At the lowest level is the Bank of Canada vault that would store gold in the event of a disaster (radioactive gold is not so valuable); it has the biggest vault door I've ever seen, and has a rectangular hallway around it with a mirror in each corner so a guard standing in one place could see all the way around.
It's an interesting piece of history that may yet come in handy if the Chinese Communist Party deploys biological or nuclear weapons.
I always liked Slow Wave... they're all write-ups of people's dreams. It's interesting—and often hilarious—to see the oddities that pass through people's minds while they sleep.