> You can't just install a root cert over the network. It requires machine admin approval, which is implicit if you've joined a NT domain [..]
You said "implicit" and I think that's the key word here. I'm imagining the user clicked on "join NT domain" and I imagine there were no warnings that this is a very dangerous thing to do. It's perfectly conceivable that people will do this without realising how dangerous it is.
In essence, you give up control of your laptop and say to the NT domain "do what you will". In this case, it involved installing the school's root CA, but it could equally install trojan software or other activity to compromise the security of laptop.
Joining an NT domain is, perhaps, the right thing to do under some circumstances; however, it should come with a hefty warning that you must completely trust the admins of this NT domain and that the future security of the laptop is dependent on this trust.
My impression is that no such warning was issued; this is the elephant.
In theory at least, Verisign would never issue a certificate for "amazon.com" to the school --- at least, they try very hard not to. Verisigns business is based on people trusting them to vet who they give certificates to. If they gave an "amazon.com" certificate to a school then they would be out of business pretty quickly. There are examples of CAs going out of business for exactly this reason: no longer being trustworthy.
The point here is that, when using the school's WIFI, your browser will receive a certificate signed by the school's CA saying it's "amazon.com". A normal off-the-street laptop would scream blue murder at this point (or should) as something fishy is going on. A "school administered" laptop would simply accept the certificate and show the web-page.
I think you need to review you understanding of X.509. If your client trusts a Certificate Authority then it trusts certificates issued by that CA. This allows anyone who can intercept the network traffic to conduct Man In The Middle attacks. Read up on it on Wikipedia.
This is not limited to the school website.
If what is reported is true then this isn't limited to the school's website and it is a big deal.
All the comments I've read so far have been on whether or not the school is morally right in deploying a Man-In-The-Middle attack. While an interesting question, for me this is missed the big point: which OS/Web-browser is so insecure that it accepts a root certificate from the network like this?
When a Web-browser or OS accepts a new Certificate Authority certificate there is an tacit acceptance of trust: you trust that whoever holds the corresponding private key will behave responsibly --- given online banking is secured via the same security infrastructure, that's some level of trust! There's no reasonable way this can happen automatically: you, personally, must indicate that you trust the CA involved. This normally this happens transitively: by installing Firefox, or using your OS you trust the people to have selected trust-worthy CAs.
While people can point to this as another nail in the SSL/TLS coffin, it doesn't help when software is so broken like this. Any Web-browser or OS that accepts a new Root CA (either automatically or without warning the user exactly how dangerous is accepting it) is so broken that you should immediately stop using it for any secure interactions.
The coreboot project (as LinuxBIOS is now known) works for pretty well for hardware the developers have documentation for; but (and this is the kicker) no documentation, no support.
In general, people like AMD, ATI (after being bought by AMD), Tyan and Via should be credited for their support of coreboot: both directly and by providing easy access to their documentation (sorry to any companies I've forgotten).
From memory, Intel have a poor track record in providing documentation to coreboot; but, some people have reported success with Intel hardware and some processors are currently reported as Work-In-Progress.
With laptops, there's the additional problem of the embedded controllers (EC). This is a custom chip for interfacing many of the hardware "bits and bobs" one finds on a laptop. They are often a custom design by the laptop OEMs. These EC chips are (often?) highly proprietary and there's almost never any publicly available documentation.
So, I would guess that a lack of documentation from Intel and Sony would prevent coreboot from working on these laptops.
Re:The results don't mean anything!
on
The Red Team Wins
·
· Score: 1
Hmm, by eye, there looks to be a slight bias towards red overall. The 2fort stats look about even whilst gravelpit shows a far greater trend towards blue winning with about the same number of rounds.
Much more interesting is goldrush, with a striking bias towards red and the largest number of games (41,000). However, this huge effect (avr. ~80% wins for red), so I'd suspect something's wrong here.
Yeah, overall, there's looks like there might be a bias towards red, but will the picture look different in a month or two's time? Is there a systematic bias towards red (as dafrazzman suggested)? Is this an self-fulfilling prophecy ("everyone" knows how red is a better colour, so the red team are optimistic and the blue team are demoralised)?..etc... lots of questions still open.
That all said, there might be an effect, but I don't believe the results (as presented) prove it. More work is needed.
The results don't mean anything!
on
The Red Team Wins
·
· Score: 2, Informative
For a fixed number of games, there's always a bit of uncertainty about what the true probability of red winning is. The more games analysed the less this uncertainty will be.
So, to look at what this study actually tells us, we can use some simple statistics to determine what range of probabilities we're 99.999% sure the true probability of red winning lies within. (This is example #3: "The coin is tossed...").
And the answer is, given 1,347 trials (games) with a 55% red-wins outcome, the true value lies somewhere between 49% and 61% (inclusive). So we're 99.999% sure that the results have not ruled out the null hypothesis: that wearing red has no effect at all.
There may be a real effect here, but more work is needed! Until then, Occam's razor selects the simpler explanation: there's no effect.
A nice article, but the cross-compiler HOWTO is a little out-of-date (circa 1999).
Having banged my head against a wall over this for a while, I eventually managed to put together a script (based on ideas from Pieter Thysebaert) that builds and installs mingw from latest sources (gcc-3.2.1, binutils-2.13.90,...)
The script also works around a couple of problems not described in any of the HOWTOs I've read.
Its always dangerous to comment about something without the full information available. The NewScientist article is quite vague and the Science paper that the article is based on is currently unavailable on-line, but I'll risk it;)
The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)
For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.
This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication.
It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure).
The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.
The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).
The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.
Yep. I bought 8 laptops recently. They came with Windows 2k preinstalled and a "recovery partition". The laptops didn't have very big disks, and the recovery partition took up some 20% of the disk.
I needed them to dual boot (actually I was all for ditching Win. but was overruled) I also assumed that the missing CD was easily remedied.
I had a long talk with various people at IBM. They tried to palm off various ideas, including the idea that the version of W2K on the laptops isn't a full version: it was a get-you-going version!!
Finally I talked to someone more in charge.
It transpires that they will send you a Win2K CD, but you have to say "my partition table is corrupt" and pay them £20.
Not really what I expect when I buy something with Windows on it. I'll not be buying anything more from IBM in a hurry.
Ok, here are a couple ideas of possible arguments against open-source software:
if the source code is available, then
there is a tendancy for people to cooperate and produce one really good product rather than establishing many mediocre ones. This is both good and potentially bad. Good because you have a really good product to play with. Bad because this good product will tend to be used exclusively. Imagine a world where every web server used Apache. When a flaw is found and actively exploited (worms, virii, crackers,...) then at one blow all web sites could be taken down, which is bad.
Free software is based on the egalitarian ideals of empowering people. If you accept that agenda then free software is the only sensible choice. Propriatory software, therefore, must have a different agenda. If you accept the alternative agenda (which might be "make as much money as possible"), then open-source is not necessarily the ideal software distribution model. A certain class of business (e.g. hardware manufactures) might view open-source as an unacceptable risk. Personally, I might disagree, but it's not my business and not my agenda.
Both arguements are fairly easy to refute, but they might help start some discussion...
I'm in favour of ISPs locking out infected machines that have demonstrated no attempt at fixing the problem. After all, these people have shown a blatant distregard of basic sysadmin responsibilies: how long has CodeRed been known about now?
However, here's a suggestion for a better response than simply removing Internet access to/from infected machines. The ISP runs some kind of DMZ server, but on the DSL side. All web traffic from infect machines is redirected to that one server (via transparent proxying), all other traffic is blocked. That way the end user can instantly see what's wrong. The ISP can also mirror the relevant patches on the DMZ so the end-user can get back up again as fast as possible.
It would take some setting up initially, but would reap substantial rewards in the long run.
> It also installs a backdoor in the infected host,
> listening on UDP port 5503 or higher.
>
> An attacker could connect to this port via TCP and...
This is impossible. TCP and UDP are independent protocols sitting on IP. You can't talk to a TCP port with UDP (or visa versa).
According to qualys'
actual release, an incoming UDP packet will trigger the compromised machine to initiate an outgoing TCP connection. Similar effect, but different net traffic.
The reason there aren't (and will never officially be) any software DVD players on Linux is because the Linux kernel is open-source, and thus not guaranteed to be trusted
Yep, you can't really trust the kernel not to have been modified, but aside from the windows-can-be-hacked-too idea, the main reason is that encryption doesn't solve copy protection problems. Encryption allows people (like Intel) to charge fees to everyone else who wants to use their technology.
If the video is, at any time, on some well-known medium (e.g. DVD, Internet, EM radiation), then it can be copied. The only ways of preventing copying is either:
to make it impossible to access the video medium (how do you watch the film)
to record it on some new medium and not tell anyone about it (and hope noone figures it out or leaks info)
or make the blank media either too expensive, or unavailable (both apply to CSS/DVD at the moment)
So it's shaping up into a fight to the death between Linux and copyright control mechanisms.
Yes, this will probably end up being quite a battle, but it does not have anything to do with copy-protection. I have a bad feeling that this "detail" will get lost in the noise: "those Linux people, they just want to pirate everything"...
Encryption (or more specifically encipherment) has two main aims:
To keep a message secret.
To authenticate the message as genuinely from the author.
These translate into the video world as:
Only people who (pay to) have the keys can view the content.
Only people who (pay to) have the keys can produce videos.
Encryption has fsck all to do with copying. The whole point is that you can give the message (or video content) to anyone - you trust your encryption algorithm to be up to scratch.
I've got a couple of questions I'd like to ask. I thought I'd cheat and put them together in the same post.
There's been a lot of talk about how Linux/Solaris boxes where responsible for the DDoS attacks (slaves actually causing the DDoS). Is this true? and if so why do you think, with the multitude of Win 9x/NT boxes on the net, few or no NT machines were used?
How did you end up a Software Engineer and Consultant for C&C, University of Washington? Which companies did you work for? -- or did you stay in academia?
Fusion shouldn't be as messy as fission. Fissions big problem is the Uranium by-products, which take ages to decay. Fusion does suffer from the container becoming radioactive; but with the materials proposed, it should have a half-life of around 10 years or so.
Long, but not too long.
Yes, we do have a great source of fusion generated power: the Sun (or more specifically solar-power, wave-power, bio-mass,...) but it isn't enough to meet projected energy requirements. There's a report by the EU (sorry, can't remember a source off the top of my head) that looked at all the available sources of energy (including fission) and there just won't be enough to go around without something happening. The report was pro-fusion so it recommended that the "something" be the development of fusion reactors.
I think JET (Joint European Torus) achieved "break-even" somepoint by add more (slightly) radioactive tritium to the deutrium/tritium mix.
The problem with the Lawson criteria is to get the containment time up (ie how long the plasma stays a plasma). This is were JET fell short and the mystic ITEA should do better!
Slashdot Mirror
> You can't just install a root cert over the network. It requires machine admin approval, which is implicit if you've joined a NT domain [..]
You said "implicit" and I think that's the key word here. I'm imagining the user clicked on "join NT domain" and I imagine there were no warnings that this is a very dangerous thing to do. It's perfectly conceivable that people will do this without realising how dangerous it is.
In essence, you give up control of your laptop and say to the NT domain "do what you will". In this case, it involved installing the school's root CA, but it could equally install trojan software or other activity to compromise the security of laptop.
Joining an NT domain is, perhaps, the right thing to do under some circumstances; however, it should come with a hefty warning that you must completely trust the admins of this NT domain and that the future security of the laptop is dependent on this trust.
My impression is that no such warning was issued; this is the elephant.
In theory at least, Verisign would never issue a certificate for "amazon.com" to the school --- at least, they try very hard not to. Verisigns business is based on people trusting them to vet who they give certificates to. If they gave an "amazon.com" certificate to a school then they would be out of business pretty quickly. There are examples of CAs going out of business for exactly this reason: no longer being trustworthy.
The point here is that, when using the school's WIFI, your browser will receive a certificate signed by the school's CA saying it's "amazon.com". A normal off-the-street laptop would scream blue murder at this point (or should) as something fishy is going on. A "school administered" laptop would simply accept the certificate and show the web-page.
I think you need to review you understanding of X.509. If your client trusts a Certificate Authority then it trusts certificates issued by that CA. This allows anyone who can intercept the network traffic to conduct Man In The Middle attacks. Read up on it on Wikipedia.
This is not limited to the school website.
If what is reported is true then this isn't limited to the school's website and it is a big deal.
No, this explanation doesn't pass muster.
If you can't allow secure web-browsing then don't allow it.
There is no excuse for breaking the security system used for online banking.
Apart from any moral issues, consider the liability if someone else gets hold of your private key and empties everyone's bank accounts.
All the comments I've read so far have been on whether or not the school is morally right in deploying a Man-In-The-Middle attack. While an interesting question, for me this is missed the big point: which OS/Web-browser is so insecure that it accepts a root certificate from the network like this?
When a Web-browser or OS accepts a new Certificate Authority certificate there is an tacit acceptance of trust: you trust that whoever holds the corresponding private key will behave responsibly --- given online banking is secured via the same security infrastructure, that's some level of trust! There's no reasonable way this can happen automatically: you, personally, must indicate that you trust the CA involved. This normally this happens transitively: by installing Firefox, or using your OS you trust the people to have selected trust-worthy CAs.
While people can point to this as another nail in the SSL/TLS coffin, it doesn't help when software is so broken like this. Any Web-browser or OS that accepts a new Root CA (either automatically or without warning the user exactly how dangerous is accepting it) is so broken that you should immediately stop using it for any secure interactions.
Not forgotting (seeminly multiple) countries closing their airspace on the chance that you might be on board.
In the short term, no.
The coreboot project (as LinuxBIOS is now known) works for pretty well for hardware the developers have documentation for; but (and this is the kicker) no documentation, no support.
In general, people like AMD, ATI (after being bought by AMD), Tyan and Via should be credited for their support of coreboot: both directly and by providing easy access to their documentation (sorry to any companies I've forgotten).
From memory, Intel have a poor track record in providing documentation to coreboot; but, some people have reported success with Intel hardware and some processors are currently reported as Work-In-Progress.
With laptops, there's the additional problem of the embedded controllers (EC). This is a custom chip for interfacing many of the hardware "bits and bobs" one finds on a laptop. They are often a custom design by the laptop OEMs. These EC chips are (often?) highly proprietary and there's almost never any publicly available documentation.
So, I would guess that a lack of documentation from Intel and Sony would prevent coreboot from working on these laptops.
Much more interesting is goldrush, with a striking bias towards red and the largest number of games (41,000). However, this huge effect (avr. ~80% wins for red), so I'd suspect something's wrong here.
Yeah, overall, there's looks like there might be a bias towards red, but will the picture look different in a month or two's time? Is there a systematic bias towards red (as dafrazzman suggested)? Is this an self-fulfilling prophecy ("everyone" knows how red is a better colour, so the red team are optimistic and the blue team are demoralised)?
That all said, there might be an effect, but I don't believe the results (as presented) prove it. More work is needed.
So, to look at what this study actually tells us, we can use some simple statistics to determine what range of probabilities we're 99.999% sure the true probability of red winning lies within. (This is example #3: "The coin is tossed...").
And the answer is, given 1,347 trials (games) with a 55% red-wins outcome, the true value lies somewhere between 49% and 61% (inclusive).
So we're 99.999% sure that the results have not ruled out the null hypothesis: that wearing red has no effect at all.
There may be a real effect here, but more work is needed! Until then, Occam's razor selects the simpler explanation: there's no effect.
Sounds similar to a project I'm working on called MonAMI, which aims to be more flexible, but is currently less mature.
Having banged my head against a wall over this for a while, I eventually managed to put together a script (based on ideas from Pieter Thysebaert) that builds and installs mingw from latest sources (gcc-3.2.1, binutils-2.13.90,
The script also works around a couple of problems not described in any of the HOWTOs I've read.
Anyway, download it from here
The extent to which communication is a bottleneck in parallel processing depends strongly on the problem at hand and the algorithm used to tackle it. Some problems are amenable to batch processing (e.g. Seti@home), others require some level of boundary-synchonisation (simple fluid codes), others require synchronisation across all nodes (e.g. more complex plasma simulations)
For batch processing tasks, there isn't an issue. For the other's the loose synchronisation may be acceptable depending on the knock-on effect. Loosening the synchronisation obviously decreases the network and infrastructural burden on the job allowing the algorithm to scale better, but the effect of this has to be carefully studied.
This is important to the application developer, but is not particularly relevent to grids per-say. Grid activity, at the moment, is mainly towards developing code at a slightly lower level than application-dependant communication. It is already building up an infrastructure in which jobs can run which tries to remove any dependancy on a central machine. This is because having a central server is a design that doesn't scale well (and also introduces a single point-of-failure). The Globus toolkit provides a basic distributed environment for batch parallel processing, including a PKI-based Grid security system: GSI.
On top of this, several projects are developing extra functionality. For example, the DataGrid project is adding may component, such as automatic target selection, fabrication management (site management, fault tolerance, ...), data management (replica selection, management and optimisation, grid-based RDBMS), network monitoring infrastructure and so on.
The basic model is currently batch-processing, but this will be extended soon to include sub-jobs (both in parallel and with a dependency tree) and an abstract information communication system which could be used for intra-job communication (R-GMA).
The applications will need to be coded carefully to fully exploit the grid, and reducing network overhead is an important part of this, but The Grid isn't quite at that stage, yet. But we're close to having the software needed for people to just submit jobs to the grid, without caring who provides the computing resource, or the geographical location they'll run.
Yep. I bought 8 laptops recently. They came with Windows 2k preinstalled and a "recovery partition". The laptops didn't have very big disks, and the recovery partition took up some 20% of the disk.
I needed them to dual boot (actually I was all for ditching Win. but was overruled) I also assumed that the missing CD was easily remedied.
I had a long talk with various people at IBM. They tried to palm off various ideas, including the idea that the version of W2K on the laptops isn't a full version: it was a get-you-going version!!
Finally I talked to someone more in charge.
It transpires that they will send you a Win2K CD, but you have to say "my partition table is corrupt" and pay them £20.
Not really what I expect when I buy something with Windows on it. I'll not be buying anything more from IBM in a hurry.
Well done you two.
Have a good life together!
Ok, here are a couple ideas of possible arguments against open-source software:
- if the source code is available, then
there is a tendancy for people to cooperate and produce one really good product rather than establishing many mediocre ones. This is both good and potentially bad. Good because you have a really good product to play with. Bad because this good product will tend to be used exclusively. Imagine a world where every web server used Apache. When a flaw is found and actively exploited (worms, virii, crackers,
...) then at one blow all web sites could be taken down, which is bad.
- Free software is based on the egalitarian ideals of empowering people. If you accept that agenda then free software is the only sensible choice. Propriatory software, therefore, must have a different agenda. If you accept the alternative agenda (which might be "make as much money as possible"), then open-source is not necessarily the ideal software distribution model. A certain class of business (e.g. hardware manufactures) might view open-source as an unacceptable risk. Personally, I might disagree, but it's not my business and not my agenda.
Both arguements are fairly easy to refute, but they might help start some discussionThoughts?
I'm in favour of ISPs locking out infected machines that have demonstrated no attempt at fixing the problem. After all, these people have shown a blatant distregard of basic sysadmin responsibilies: how long has CodeRed been known about now?
However, here's a suggestion for a better response than simply removing Internet access to/from infected machines. The ISP runs some kind of DMZ server, but on the DSL side. All web traffic from infect machines is redirected to that one server (via transparent proxying), all other traffic is blocked. That way the end user can instantly see what's wrong. The ISP can also mirror the relevant patches on the DMZ so the end-user can get back up again as fast as possible.
It would take some setting up initially, but would reap substantial rewards in the long run.
This is impossible. TCP and UDP are independent protocols sitting on IP. You can't talk to a TCP port with UDP (or visa versa).
According to qualys' actual release, an incoming UDP packet will trigger the compromised machine to initiate an outgoing TCP connection. Similar effect, but different net traffic.
For information about the M25 automatic speed-limit have a look at this page. Apparently, they called it MIDAS!
| What? you were expecting
Are you sitting behind an enforced HTML proxy?
| What? you were expecting
This sort of thing is bad
| What? you were expecting
Yep, you can't really trust the kernel not to have been modified, but aside from the windows-can-be-hacked-too idea, the main reason is that encryption doesn't solve copy protection problems. Encryption allows people (like Intel) to charge fees to everyone else who wants to use their technology.
If the video is, at any time, on some well-known medium (e.g. DVD, Internet, EM radiation), then it can be copied. The only ways of preventing copying is either:
- to make it impossible to access the video medium (how do you watch the film)
- to record it on some new medium and not tell anyone about it (and hope noone figures it out or leaks info)
- or make the blank media either too expensive, or unavailable (both apply to CSS/DVD at the moment)
So it's shaping up into a fight to the death between Linux and copyright control mechanisms.Yes, this will probably end up being quite a battle, but it does not have anything to do with copy-protection. I have a bad feeling that this "detail" will get lost in the noise: "those Linux people, they just want to pirate everything" ...
| What? you were expecting
This is CSS all again...
Encryption (or more specifically encipherment) has two main aims:
These translate into the video world as:
Encryption has fsck all to do with copying. The whole point is that you can give the message (or video content) to anyone - you trust your encryption algorithm to be up to scratch.
| What? you were expecting
Hi Dave,
I've got a couple of questions I'd like to ask. I thought I'd cheat and put them together in the same post.
Is this true?
and if so why do you think, with the multitude of Win 9x/NT boxes on the net, few or no NT machines were used?
Cheers,
| What? you were expecting
Long, but not too long.
Yes, we do have a great source of fusion generated power: the Sun (or more specifically solar-power, wave-power, bio-mass, ...) but it isn't enough to meet projected energy requirements. There's a report by the EU (sorry, can't remember a source off the top of my head) that looked at all the available sources of energy (including fission) and there just won't be enough to go around without something happening. The report was pro-fusion so it recommended that the "something" be the development of fusion reactors.
The problem with the Lawson criteria is to get the containment time up (ie how long the plasma stays a plasma). This is were JET fell short and the mystic ITEA should do better!