I recall a story, probably from here in Canada, that a utility had to replace wind generators on remote sites with much more expensive solar panels, because "hunters" found the moving blades an irresistible target. (yes there are yahoos here too - you can find informal rifle ranges up logging roads. They're just a bit quieter and more polite:-)
I have to wonder at the brains of someone who would try to shoot down a high-voltage transmission line, considering what might happen if they succeeded and the line landed anywhere near them, their truck or friends.
I'd like to see the actual paper, which doesn't seem to be linked. Do they mean 25 purchases to one location, or 25 purchases per delivery run?
Buses, by the way, have a similar problem. Buses have good energy efficiency when full and when going roughly from source to destination. They have terrible efficiency when they're running winding routes designed to cover as much area as possible, carrying few people. Which is the typical suburban bus situation.
The figure for 25 purchases refers to "25 orders delivered at the same time" This is from Plepy's paper "the grey side of ict" http://www.graduateinstitute.ch/aspd/wsis/DOC/200EN.PDF, which quotes a 1999 paper by G. Jönson, F. Orremo, C. Wallin and K. Ringsberg. Which I could not find.. time to go home and eat..:-7
A rootkit as I understand is a software package run after one has got root. The intent of the rootkit is to hide the nefarious activity (IRC server, warez stash etc.) from the user or admin. LKM rootkits tell the kernel to ignore certain process id's, ip addresses etc. while old-style rootkits overwrite programs like ps, top, ls with modified ones. A rootkit might contain a backdoor as part of the kit.
The situation appears to be exactly as described by Ksplice. CVE-2010-3081 has been discussed on RedHat forums and elsewhere. The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268 does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l). From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience. A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor. More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.
I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.
I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into/proc.
Give up passwords, move to certificates, SSH keys, biometrics etc. It doesn't matter how good your password is, it's toast if someone grabs it off a hacked server/client/WiFi (BTW there's some Brazilian hackers busy installing trojan sshd everywhere they can get to). Re. stupid website passwords, I've started generating random 20-char passwords and using FireFox to remember them (with a master password, of course). A bit of a pain moving between computers, I really need to get some secure sync scheme sorted out (they do exist)
There have been suggestions that if this leak had happened in the Arctic, it could have an environmental impact for centuries, quite apart from being a lot more difficult to fix. I was wondering how the environmental impact compares with nuclear accidents. As a child, I remember reading of the Windscale leak poisoning pastures with radioactive iodine, so that a month's milk was thrown away. The Deepwater Horizon leak has already closed down shrimping and other fisheries for an extended period, with no end in sight. Chernobyl, as I recall, has turned into a kind of wildlife refuge (disappointing legions of Farside fans with an absence of 3-eyed deer and size-legged wolves)
The practice of using a single privileged account for everything - banking, reading slashdot, downloading porn - may be doomed, and about time too. But I still think there's hope for using a single piece of hardware and a single network. Even if it comes down to using not just separate accounts, but separate cores, for play and work. Last time I looked (a while back) some CPU manufacturers were adding features for process separation but the OS had not yet implemented support. End-to-end encryption should protect your data in transit, if not your usage pattern, though there a a few things to fix in SSL implementations to prevent MITM.
I saw a documentary a while ago about a plane flying through an ash cloud at night over the Andes - all 4 engines quit. There was also abrasion of the windshield as I recall, plus electrical discharges around the plane that probably affected radio communications. Several media articles have explained the effects of ash on jet engines, and it seemed prudent not to fly following the volcano eruption. There were initially no standards on safe levels from the engine manufacturers, so zero tolerance as a first response was sensible. Later, some testing was done, and measurements of ash density determined that some airspace could be opened. The last report I read said that planes were flying but engines were being inspected before and after every flight. One might argue that the tests should have been done sooner.
Adobe Acrobat will do some of this, if not all. It does not require a central document repository and works across platforms - at least, as I recall, documents can be signed and verified on Linux though must at present be created in Distiller on Windows. As PDF is a somewhat open standard there is at least the possibility of other tools supporting the digital signatures. A document may have multiple signatures placed in the document body in a natural way - i.e. where you might have an ink signature box. You need a certificate authority of your own to issue certificates to signers - after all, anyone can get a Verisign certificate, and who's to say that Joe Bloggs, even he is the real Joe with passport to prove it, can sign off on your reactor design ? There are some options to set when the document is created that control whether it can be signed by the free cross-platform reader or only by the paid-for Distiller. Drawbacks vs. GPG digital signatures - only works on PDF files, must be created on Windows. Advantages - natural signing/verification mechanism built into the reader.
what's this "You failed to confirm you are a human. Please start from the beginning and try again. If you are a human, we apologize for the inconvenience" thing ?
So, reading this backwards, I presume we need new cable modems for native IPv6 support ? And if Comcast's doing a trial, I guess they are in production somewhere.
From a presentation by Tata Communications: "the promises of IPv6" Restores p2p communication Mobility
* Much easier roaming
* Better spectrum utilization
* Better battery life! Security
* IPsec mandatory Multicast Better QoS (flow labels) Auto configuration
* Mobile Ad-Hoc networking
* Mobile networks
* Sensor networks
* Plug and Play networks Permanent addresses
* Identity (CLID)
* Traceability (RFID)
* Addressability!
* IP address based billing
But yes, staying in business. Even if you have enough IPv4 to last you for years, you will start to find new services and businesses that you can't use, or can't get to without going through some kind of tunnel/proxy
Request IPv6 records only: bash-3.2$ host -t aaaa ipv6.google.com ipv6.google.com is an alias for ipv6.l.google.com. ipv6.l.google.com has IPv6 address 2001:4860:800b::67 ipv6.l.google.com has IPv6 address 2001:4860:800b::68
bash-3.2$ traceroute6 ipv6.google.com
doesn't work from here:-( no tunnel set up
It's not Google restricting the use, it's the.org registrar. I just happened to choose google.org as an example.
Whois was never designed as a general search engine, and it seems reasonable to me that the operators can throttle access to their service if that allows it to continue to run for free. If they
did not, the service would crash or the pipe saturate under the load of spammers looking for email addresses, and then everyone would complain that whois was broken and stop using it.
Well, yes. But I quote, from jwhois google.org:
"..under no
circumstances will you use this data to..enable high volume,
automated, electronic processes that send queries or data to the systems of
Registry Operator or any ICANN-Accredited Registrar, except as reasonably
necessary to register domain names or modify existing registrations."
I have an idea I had seen one whois server apply throttling, and
not return more than N responses/hour. I forget the value of N.
Whois providers get pissed off if you start making millions of queries. I used to analyse logs with thousands of entries, and carefully cached netblock ranges in a database to avoid hitting them too often, but that might not scale to millions.
I remember seeing one of these things on a thing like an R/C model car on a wire, dropped down from under the police car to run forward under the suspect's car and zap it from underneath. Crazy.
I aso recall, I think, a HERF gun described by Winn Schwartau at DEFCON 7 that used explosives to move a conductor *really fast* through a magnetic field, generating a huge EMP.
I have my doubts about using anything like this in a city - too much chance of getting innocent bystanders, traffic light controllers etc.
Maybe they could mount one in a helicopter and zap someone fleeing on the highway.
A comment from an IPv6 workshop I attended last year, from (I think) Tata.com : content providers need to get on IPv6 else they will be left behind. As customers start to move to v6 (perhaps starting in Asia, but it doesn't really matter), any org that puts hurdles in the way of customers connecting at full speed is going to lose out.
Last time I looked, forwarding was a show-stopper. Sender rewriting was complicated, and user's mail client configs would be broken if they used a local SMTP server at home or while travelling.
http://www.lrwc.org/documents/Civil.Disobedience.Guide.November.20.2009.F.pdf
This "protesters guide to civil disobedience" was discussed recently on CBC Radio. Interesting tidbits about assaulting a police officer.
I suspect career criminals don't have this trouble - they figured out at 14 how to deal with law enforcement:-7
Interesting interview on CBC radio recently with Sue Gardner, Executive Director of the Wikimedia Foundation. She used to work for the CBC, a fairly buttoned-down workplace. When she was asked about the culture differences, and hiring people, she noted that by the time you've seen 500 drunken party photos, you realize that you can't find any young hires that don't have some nonsense in their past. Like the recent study on the effects of porn that could not find any controls (guys who've never consumed any).
So a blameless life experience starts to look fishy - either it shows a lack of initiative or courage, or it's been doctored in some way.
Doubt and skepticism are the basis of the scientific method. You don't trust some theory just because the proposer got tenure, you go out and do an experiment to prove it. Then everyone says your experimental data is flawed until two other guys have replicated the effect and got the same result. With climate change, enough other guys have reproduced the results in enough different fields that all the serious doubt was over years ago. Now they are arguing over whether uncertainty in cloud modelling means we get 2C rise in temperature or 3C.
BTW, some of the climate models are available for download for those that want to play
Yes, that's how to make a nonprivileged exploit (mess with.bash_profile etc.)
Ideally, the.deb package should have been digitally signed, and the person who signed it should have checked to make sure it was safe. Then if you only install packages from trusted repositories and check the sigs, you are safe (unless the signing keys are hacked, which happened to Fedora. Or they were playing safe, in that they might have been hacked. I forget)
In practice, that only works for corporate deployment (protection against autohacking of the entire client PC base). People will always download toys without checking the provenance.
I concur. On some Firefox versions I think there was a separate box "encrypt passwords". Use it.
Apart from ease-of-use, this method is proof against keyloggers (since you are not actually typing the website password).
It also makes it less of a headache to use a different password for each website. The question you should ask is, "Do I trust molewhacker.com with my day-trading password?" and so on.
I recently changed most of my online passwords to unique random 20-character strings - only the odd glitch where a site truncated it, or did not accept certain punctuation.
To be sure, it's a pain to transfer them to a different computer (I use a GPG encrypted textfile), and my bank uses a method that the browser won't remember (so it still has a short more memorable passphrase...)
I recall a story, probably from here in Canada, that a utility had to replace wind generators on remote sites with much more expensive solar panels, because "hunters" found the moving blades an irresistible target. (yes there are yahoos here too - you can find informal rifle ranges up logging roads. They're just a bit quieter and more polite :-)
I have to wonder at the brains of someone who would try to shoot down a high-voltage transmission line, considering what might happen if they succeeded and the line landed anywhere near them, their truck or friends.
I'd like to see the actual paper, which doesn't seem to be linked. Do they mean 25 purchases to one location, or 25 purchases per delivery run?
Buses, by the way, have a similar problem. Buses have good energy efficiency when full and when going roughly from source to destination. They have terrible efficiency when they're running winding routes designed to cover as much area as possible, carrying few people. Which is the typical suburban bus situation.
The figure for 25 purchases refers to "25 orders delivered at the same time" This is from Plepy's paper "the grey side of ict" http://www.graduateinstitute.ch/aspd/wsis/DOC/200EN.PDF, which quotes a 1999 paper by G. Jönson, F. Orremo, C. Wallin and K. Ringsberg. Which I could not find .. time to go home and eat ..:-7
Not having the actual study, it's hard to say, but it seems like there's some big assumptions here.
http://www.theiet.org/factfiles/transport/unintended-page.cfm
Looks like it's a meta-study; it seems to quote this: http://is4ie.net/images/Matthews.pdf, quoted by someone else, which is a 2001 study from the US. Also this: http://onlinelibrary.wiley.com/doi/10.1162/108819802763471816/pdf - a study of online book retailing in Japan in 2001.
I may have got this all wrong, and there may be some new UK research I didn't find.
A rootkit as I understand is a software package run after one has got root. The intent of the rootkit is to hide the nefarious activity (IRC server, warez stash etc.) from the user or admin. LKM rootkits tell the kernel to ignore certain process id's, ip addresses etc. while old-style rootkits overwrite programs like ps, top, ls with modified ones.
A rootkit might contain a backdoor as part of the kit.
The situation appears to be exactly as described by Ksplice.
CVE-2010-3081 has been discussed on RedHat forums and elsewhere.
The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268
does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l).
From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience.
A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor.
More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.
I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so
the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my
test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.
I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used /proc.
in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into
Give up passwords, move to certificates, SSH keys, biometrics etc. It doesn't matter how good your password is, it's toast if someone grabs it off a hacked server/client/WiFi (BTW there's some Brazilian hackers busy installing trojan sshd everywhere they can get to).
Re. stupid website passwords, I've started generating random 20-char passwords and using FireFox to remember them (with a master password, of course). A bit of a pain moving between computers, I really need to get some secure sync scheme sorted out (they do exist)
There have been suggestions that if this leak had happened in the Arctic, it could have an environmental impact for centuries, quite apart from being a lot more difficult to fix. I was wondering how the environmental impact compares with nuclear accidents. As a child, I remember reading of the Windscale leak poisoning pastures with radioactive iodine, so that a month's milk was thrown away. The Deepwater Horizon leak has already closed down shrimping and other fisheries for an extended period, with no end in sight.
Chernobyl, as I recall, has turned into a kind of wildlife refuge (disappointing legions of Farside fans with an absence of 3-eyed deer and size-legged wolves)
The practice of using a single privileged account for everything - banking, reading slashdot, downloading porn - may be doomed, and about time too. But I still think there's hope for using a single piece of hardware and a single network. Even if it comes down to using not just separate accounts, but separate cores, for play and work. Last time I looked (a while back) some CPU manufacturers were adding features for process separation but the OS had not yet implemented support. End-to-end encryption should protect your data in transit, if not your usage pattern, though there a a few things to fix in SSL implementations to prevent MITM.
I saw a documentary a while ago about a plane flying through an ash cloud at night over the Andes - all 4 engines quit. There was also abrasion of
the windshield as I recall, plus electrical discharges around the plane that probably affected radio communications.
Several media articles have explained the effects of ash on jet engines, and it seemed prudent not to fly following the volcano eruption. There were initially no standards on safe levels from the engine manufacturers, so zero tolerance as a first response was sensible. Later, some testing was done, and measurements of ash density determined that some airspace could be opened. The last report I read said that planes were flying but engines were being inspected before and after every flight. One might argue that the tests should have been done sooner.
Adobe Acrobat will do some of this, if not all. It does not require a central document repository and works across platforms - at least, as I recall, documents can be signed and verified on Linux though must at present be created in Distiller on Windows. As PDF is a somewhat open standard there is at least the possibility of other tools supporting the digital signatures.
A document may have multiple signatures placed in the document body in a natural way - i.e. where you might have an ink signature box. You need a certificate authority of your own to issue certificates to signers - after all, anyone can get a Verisign certificate, and who's to say that Joe Bloggs, even he is the real Joe with passport to prove it, can sign off on your reactor design ?
There are some options to set when the document is created that control whether it can be signed by the free cross-platform reader or only by the paid-for Distiller.
Drawbacks vs. GPG digital signatures - only works on PDF files, must be created on Windows.
Advantages - natural signing/verification mechanism built into the reader.
what's this "You failed to confirm you are a human. Please start from the beginning and try again. If you are a human, we apologize for the inconvenience" thing ?
So, reading this backwards, I presume we need new cable modems for native IPv6 support ?
And if Comcast's doing a trial, I guess they are in production somewhere.
From a presentation by Tata Communications: "the promises of IPv6"
Restores p2p communication
Mobility
* Much easier roaming
* Better spectrum utilization
* Better battery life!
Security
* IPsec mandatory
Multicast
Better QoS (flow labels)
Auto configuration
* Mobile Ad-Hoc networking
* Mobile networks
* Sensor networks
* Plug and Play networks
Permanent addresses
* Identity (CLID)
* Traceability (RFID)
* Addressability!
* IP address based billing
But yes, staying in business. Even if you have enough IPv4 to last you for years, you will start to find new services and businesses that you can't use, or can't get to without going through some kind of tunnel/proxy
Request IPv6 records only:
bash-3.2$ host -t aaaa ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2001:4860:800b::67
ipv6.l.google.com has IPv6 address 2001:4860:800b::68
bash-3.2$ traceroute6 ipv6.google.com :-( no tunnel set up
doesn't work from here
It's not Google restricting the use, it's the .org registrar. I just happened to choose google.org as an example.
Whois was never designed as a general search engine, and it seems reasonable to me that the operators can throttle access to their service if that allows it to continue to run for free. If they
did not, the service would crash or the pipe saturate under the load of spammers looking for email addresses, and then everyone would complain that whois was broken and stop using it.
Well, yes. But I quote, from jwhois google.org: "..under no circumstances will you use this data to..enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations." I have an idea I had seen one whois server apply throttling, and not return more than N responses/hour. I forget the value of N.
Whois providers get pissed off if you start making millions of queries. I used to analyse logs with thousands of entries, and carefully cached netblock ranges in a database to avoid hitting them too often, but that might not scale to millions.
I remember seeing one of these things on a thing like an R/C model car on a wire, dropped down from under the police car to run forward under the suspect's car and zap it from underneath. Crazy. I aso recall, I think, a HERF gun described by Winn Schwartau at DEFCON 7 that used explosives to move a conductor *really fast* through a magnetic field, generating a huge EMP. I have my doubts about using anything like this in a city - too much chance of getting innocent bystanders, traffic light controllers etc. Maybe they could mount one in a helicopter and zap someone fleeing on the highway.
A comment from an IPv6 workshop I attended last year, from (I think) Tata.com : content providers need to get on IPv6 else they will be left behind. As customers start to move to v6 (perhaps starting in Asia, but it doesn't really matter), any org that puts hurdles in the way of customers connecting at full speed is going to lose out.
Last time I looked, forwarding was a show-stopper. Sender rewriting was complicated, and user's mail client configs would be broken if they used a local SMTP server at home or while travelling.
http://www.lrwc.org/documents/Civil.Disobedience.Guide.November.20.2009.F.pdf This "protesters guide to civil disobedience" was discussed recently on CBC Radio. Interesting tidbits about assaulting a police officer. I suspect career criminals don't have this trouble - they figured out at 14 how to deal with law enforcement :-7
Interesting interview on CBC radio recently with Sue Gardner, Executive Director of the Wikimedia Foundation. She used to work for the CBC, a fairly buttoned-down workplace. When she was asked about the culture differences, and hiring people, she noted that by the time you've seen 500 drunken party photos, you realize that you can't find any young hires that don't have some nonsense in their past. Like the recent study on the effects of porn that could not find any controls (guys who've never consumed any). So a blameless life experience starts to look fishy - either it shows a lack of initiative or courage, or it's been doctored in some way.
Doubt and skepticism are the basis of the scientific method. You don't trust some theory just because the proposer got tenure, you go out and do an experiment to prove it. Then everyone says your experimental data is flawed until two other guys have replicated the effect and got the same result. With climate change, enough other guys have reproduced the results in enough different fields that all the serious doubt was over years ago. Now they are arguing over whether uncertainty in cloud modelling means we get 2C rise in temperature or 3C. BTW, some of the climate models are available for download for those that want to play
Yes, that's how to make a nonprivileged exploit (mess with .bash_profile etc.)
Ideally, the .deb package should have been digitally signed, and the person who signed it should have checked to make sure it was safe. Then if you only install packages from trusted repositories and check the sigs, you are safe (unless the signing keys are hacked, which happened to Fedora. Or they were playing safe, in that they might have been hacked. I forget)
In practice, that only works for corporate deployment (protection against autohacking of the entire client PC base). People will always download toys without checking the provenance.
I concur. On some Firefox versions I think there was a separate box "encrypt passwords". Use it. Apart from ease-of-use, this method is proof against keyloggers (since you are not actually typing the website password). It also makes it less of a headache to use a different password for each website. The question you should ask is, "Do I trust molewhacker.com with my day-trading password?" and so on. I recently changed most of my online passwords to unique random 20-character strings - only the odd glitch where a site truncated it, or did not accept certain punctuation. To be sure, it's a pain to transfer them to a different computer (I use a GPG encrypted textfile), and my bank uses a method that the browser won't remember (so it still has a short more memorable passphrase...)