"could allow an attacker to execute arbitrary code with the privileges of the user running IE" This is why you run as a restricted user rather than administrator or power user. Restricted users don't have write or modify permissions to the WINNT or Program Files directories or subdirectories. And they certainly don't have permission to screw with the registry.
Even a user without admin privileges can turn the box into a spam relay (or a DDoS agent), so reducing privileges is only a very partial solution.
There was even a worm which exploited the vulnerability behind the last item on that list.
The problem with Apache vs. IIS comparisons is that they are hardly fair. IIS comes with tons of dangerous examples and extensions. Bugs in widespread Apache modules are usually not attributed to Apache itself. There's nothing wrong with that, but it doesn't give you much information which web server, when configured properly, is more secure.
We mainly use Cisco Netflow Data Export to detect and analyze network anomalities. If your router doesn't support netflow export, you might be able to hook a PC to switch at a monitor port and use some tool like fprobe or nProbe to generate flow data.
A short-term archive of flow data is extremely useful for handling all kinds of abuse complaints (did you know that a significant portion is forged?) and detecting worms, outgoing DoS attacks etc. on your own network.
Honestly, researcher communities (especially the academic ones) are disdainful to the "achievements" of "industrial research". The reject rates on industrial papers have been pretty high (usually more than 50%). This is because that the "innovations" of industrial "research" are more or less either one or some of the following: rehashing old ideas, implementing old ideas with new looks / new aspects / into new problems which often not worth mentioning, combining several old ideas in some obvious ways.
Don't forget that often, there is no need (or time) to write a paper. For example, in the area of transaction processing, a lot of research went directly into commercial products, and quite a few of the underlying principles were only rediscovered in academia.
But I'm getting so tired of these virus 'alerts' constantly bombarding me day in and day out!
I tend to agree. Most of these alerts turn out to be unfounded, and important developments are not announced at all. What about the first Beagle/Bagle wave, for example?
If you are responsible for insecurity on some organization's network, you should gather as much statistics as you can, and get involved in some of the trust-based communities that deal with security. Try to share your observations and knowledge with like-minded people. FIRST or your regional FIRST look-alike could be a good start (if they still actively engage in such discussions).
Statistics and discussions with peers enable you to predict the impact of new developments to some degree. A threat meter at 9.6 doesn't help at all, and press reports written after seeing such alerts don't do it, either.
(Yeah, the 9.6 is purely fictional, I haven't seen the DHS report that leaked to the Washington Post and don't even know if the DHS is now involved in the botnet rating business.)
I haven't got the exact figures, but I reckon 99% of all code written out there must be written in Imperative (sometimes pseudo OO) languages.
There are lots of applications implemented in Excel spreadsheets. The stuff some people (who consider themselves non-programmers) do with Excel (or any other spreadsheet) is just amazing.
Excel is a bit limited (especially if you don't use VBA), but it's certainly some form of functional, purely applicative programming.
I disagree -- there's lots of demand for Failover, especially at small/medium sites that don't want to deal with the clustering business.
Some users have SQL databases which just support their business. You seem to have users in mind whose businesses are their SQL databases (or at least they think it is, usually it's your brand or your customer, depending on your perspective).
I'm not saying that nobody needs failover, I'm only reporting my observation that quite a few proprietary database users only use a tiny subset of the functionality. Adding more functionality won't change this. 8-)
Yukon is finally going to deliver online restoration, database mirroring with automatic failover, and support for mirrored backup sets.
Let's face it, these features isn't something most users need. If Microsoft sees real trouble, they will simply slash the per-processor license cost by a factor of 50 or 100, and switching suddenly becomes a non-issue for most users.
Per-client licenses and awfully high per-processor licensing costs are the most important factor which motivates most users to attempt other solutions. Of course, the proprietary databases have important features which look very good on paper, but I've seen quite a few installations which use a multi-thousand dollar database as if it were MySQL (not even using online backup). You can get away with that if you only need a workgroup server license, but if you need 20,000 client access licenses (or multiple per-processor licenses), licensing becomes a problem and you'll certainly consider other options.
I was completely riveted by the portion of the interview that detailed the night on which Linus broke into SCO headquarters to steal their intellectual property.
For those of you who missed the SCO part in the story, here it is again:
Then there are various interesting projects going on that I'd be very interested to see: [...] i386 SysV binary compatibility (already in early stages of testing)"
As much as some people would like to deny it Porn built the internet.
UTMS is a failure in Europe, despite early announcements of porn content.
It's true that the porn industry has been more open to technology changes than the rest of the content industry. But I believe that thanks to P2P, there's a measurable fraction of Internet traffic which isn't either DNS or porn. (Yes, you can share porn over P2P networks, too -- but let's be honest, porn is not everyone's favorite content. 8-)
I know they are understaffed, what I am proposing is to let hardware do the work.
No, you propose that people develop, test and deplay countermeasures. Hardware can't do that yet.
Contrary to popular belief, IOS doesn't have a "no ip dos-attacks" command. I haven't used Junipers, but rumors has it that they also lack this important functionality.
every known DDoS method has an easily identifiable pattern.
Your Internet certainly differs significantly from mine.
Why not start helping ISP's to block this crap at the source? They are, essentially, what allowed these machines to be zombified in the first place. Aggregators and headends should already have the intelligence to block IP spoofs, which eliminates SYN floods.
It's not that simple. Network security at ISPs is usually severely understaffed (factor of 10 is not uncommon). Simple filters are easily evaded.
I've seen what happens if you install SYN flood protection on a target (well, not exactly SYN flood protection, but something which also stopped most SYN floods): some day, the attackers discover another, more obscure tool that works against the target, word spreads about it, and you are mostly back to zero. But this time, it's not a SYN flood (which is annoying as hell, but still a known quantity, so to speak), but something really obscure nobody has gathered experience with.
To some degree, the situation resembles germs in a hospital. Only few survive the constant disinfection, but these are the most troublesome ones.
Because ripping a CD doesn't require that you break any encryption.
If you make a digital copy, you bypass the Serial Copy Management System. It's far less elaborate than the DVD restrictions, but it's still there, and some devices do enforce the flags.
This is, in fact, pretty similar to Richard Stallman's philosophy, and is elaborated on in the su info page, about why su doesn't support the wheel group.
Fortunately, with PAM support, you can implement a wheel group easily.
(And yes, I'm guilty of discriminating against many users: "www-data", "nobody", "mail"...)
Where is this stated? All I see is that/usr/bin/passwd has a local root vulnerability; to me, that says that if I can exploit a buffer overflow in any arbitrary program, even an unprivileged one, I can get root on the box.
You've conveniently removed what I wrote: This is true on any *NIX system, there are tons of vulnerabilities which allow attackers who can execute code under a non-root UID to obtain root access.
It doesn't matter if you fix passwd(1). There are too many other issues, most of which still have to be discovered. You can't rely on local *NIX security, you have to use other means to stop attackers. For example, one widely-used approach is "one machine per service" or "one machine per trust domain".
Yes, because prior authentication is required. Local security on *NIX is known to be rather weak, and only the clueless rely on it for critical applications.
There are some issues with that tool, though. A safe option is plain ASCII export.
Currently, PDF export is also a possibility, but this might change in the future, as PDF evolves. Just keep in mind that when redacting a PDF document, it's not sufficient to paint black rectangles over the critical parts.
This computer reminds me of a Mercedes-Benz S-Klasse four-seater which was so heavy that only two people were allowed to drive in it. And you mustn't put anything into the rear trunk, of course.
When was the last time you heard about a public-sector IT project that succeeded?
According to the most pessimistic estimates, 30% of all public-sector IT projects succeed.
BelWue, the regional research network over here, is doing rather fine, for example.
Linux or no, it seems like pretty much every IT investment made by any government (maybe it's just the UK?) ends up becoming a steaming pile of failure that gets reported ten-times overbudget, 8 years late, and eventually gets either scrapped or audited (those being essentially the same)
What about the national do-not-call list in the US? I haven't heard of any technical problems, but it surely was (and is) a technical challenge to run it.
The problem with good, complex IT is that it stays in the background. You won't notice it until it breaks. Well-working systems aren't newsworthy.
Will Microsoft publicise the news worldwide, and show that it was completely the fault of trying to use non-Microsoft software?
I wouldn't start a war on this front because it's pretty unsafe terrain. You can't be sure that none of your own failures suddenly dominate the discussion.
Slashdot Mirror
"could allow an attacker to execute arbitrary code with the privileges of the user running IE" This is why you run as a restricted user rather than administrator or power user. Restricted users don't have write or modify permissions to the WINNT or Program Files directories or subdirectories. And they certainly don't have permission to screw with the registry.
Even a user without admin privileges can turn the box into a spam relay (or a DDoS agent), so reducing privileges is only a very partial solution.
There was even a worm which exploited the vulnerability behind the last item on that list.
The problem with Apache vs. IIS comparisons is that they are hardly fair. IIS comes with tons of dangerous examples and extensions. Bugs in widespread Apache modules are usually not attributed to Apache itself. There's nothing wrong with that, but it doesn't give you much information which web server, when configured properly, is more secure.
We mainly use Cisco Netflow Data Export to detect and analyze network anomalities. If your router doesn't support netflow export, you might be able to hook a PC to switch at a monitor port and use some tool like fprobe or nProbe to generate flow data.
A short-term archive of flow data is extremely useful for handling all kinds of abuse complaints (did you know that a significant portion is forged?) and detecting worms, outgoing DoS attacks etc. on your own network.
Honestly, researcher communities (especially the academic ones) are disdainful to the "achievements" of "industrial research". The reject rates on industrial papers have been pretty high (usually more than 50%). This is because that the "innovations" of industrial "research" are more or less either one or some of the following: rehashing old ideas, implementing old ideas with new looks / new aspects / into new problems which often not worth mentioning, combining several old ideas in some obvious ways.
Don't forget that often, there is no need (or time) to write a paper. For example, in the area of transaction processing, a lot of research went directly into commercial products, and quite a few of the underlying principles were only rediscovered in academia.
But I'm getting so tired of these virus 'alerts' constantly bombarding me day in and day out!
I tend to agree. Most of these alerts turn out to be unfounded, and important developments are not announced at all. What about the first Beagle/Bagle wave, for example?
If you are responsible for insecurity on some organization's network, you should gather as much statistics as you can, and get involved in some of the trust-based communities that deal with security. Try to share your observations and knowledge with like-minded people. FIRST or your regional FIRST look-alike could be a good start (if they still actively engage in such discussions).
Statistics and discussions with peers enable you to predict the impact of new developments to some degree. A threat meter at 9.6 doesn't help at all, and press reports written after seeing such alerts don't do it, either.
(Yeah, the 9.6 is purely fictional, I haven't seen the DHS report that leaked to the Washington Post and don't even know if the DHS is now involved in the botnet rating business.)
I haven't got the exact figures, but I reckon 99% of all code written out there must be written in Imperative (sometimes pseudo OO) languages.
There are lots of applications implemented in Excel spreadsheets. The stuff some people (who consider themselves non-programmers) do with Excel (or any other spreadsheet) is just amazing.
Excel is a bit limited (especially if you don't use VBA), but it's certainly some form of functional, purely applicative programming.
I disagree -- there's lots of demand for Failover, especially at small/medium sites that don't want to deal with the clustering business.
Some users have SQL databases which just support their business. You seem to have users in mind whose businesses are their SQL databases (or at least they think it is, usually it's your brand or your customer, depending on your perspective).
I'm not saying that nobody needs failover, I'm only reporting my observation that quite a few proprietary database users only use a tiny subset of the functionality. Adding more functionality won't change this. 8-)
Yukon is finally going to deliver online restoration, database mirroring with automatic failover, and support for mirrored backup sets.
Let's face it, these features isn't something most users need. If Microsoft sees real trouble, they will simply slash the per-processor license cost by a factor of 50 or 100, and switching suddenly becomes a non-issue for most users.
Per-client licenses and awfully high per-processor licensing costs are the most important factor which motivates most users to attempt other solutions. Of course, the proprietary databases have important features which look very good on paper, but I've seen quite a few installations which use a multi-thousand dollar database as if it were MySQL (not even using online backup). You can get away with that if you only need a workgroup server license, but if you need 20,000 client access licenses (or multiple per-processor licenses), licensing becomes a problem and you'll certainly consider other options.
I was completely riveted by the portion of the interview that detailed the night on which Linus broke into SCO headquarters to steal their intellectual property.
For those of you who missed the SCO part in the story, here it is again:
Then there are various interesting projects going on that I'd be very interested to see: [...] i386 SysV binary compatibility (already in early stages of testing)"
As much as some people would like to deny it Porn built the internet.
UTMS is a failure in Europe, despite early announcements of porn content.
It's true that the porn industry has been more open to technology changes than the rest of the content industry. But I believe that thanks to P2P, there's a measurable fraction of Internet traffic which isn't either DNS or porn. (Yes, you can share porn over P2P networks, too -- but let's be honest, porn is not everyone's favorite content. 8-)
Could you use an american proxy server to make your connection appear to come from here?
This doesn't solve the legal problems, I'm afraid.
I know they are understaffed, what I am proposing is to let hardware do the work.
No, you propose that people develop, test and deplay countermeasures. Hardware can't do that yet.
Contrary to popular belief, IOS doesn't have a "no ip dos-attacks" command. I haven't used Junipers, but rumors has it that they also lack this important functionality.
every known DDoS method has an easily identifiable pattern.
Your Internet certainly differs significantly from mine.
Why not start helping ISP's to block this crap at the source? They are, essentially, what allowed these machines to be zombified in the first place. Aggregators and headends should already have the intelligence to block IP spoofs, which eliminates SYN floods.
It's not that simple. Network security at ISPs is usually severely understaffed (factor of 10 is not uncommon). Simple filters are easily evaded.
I've seen what happens if you install SYN flood protection on a target (well, not exactly SYN flood protection, but something which also stopped most SYN floods): some day, the attackers discover another, more obscure tool that works against the target, word spreads about it, and you are mostly back to zero. But this time, it's not a SYN flood (which is annoying as hell, but still a known quantity, so to speak), but something really obscure nobody has gathered experience with.
To some degree, the situation resembles germs in a hospital. Only few survive the constant disinfection, but these are the most troublesome ones.
Mandrake makes a point of it being a totally GPL distro.
They don't included SSL support, Apache and OpenSSH?
I'm impressed. A real open-source driver from a major company...
You haven't browsed the Linux source code lately, have you?
There are at least two other Intel drivers in them.
Because ripping a CD doesn't require that you break any encryption.
If you make a digital copy, you bypass the Serial Copy Management System. It's far less elaborate than the DVD restrictions, but it's still there, and some devices do enforce the flags.
This is, in fact, pretty similar to Richard Stallman's philosophy, and is elaborated on in the su info page, about why su doesn't support the wheel group.
Fortunately, with PAM support, you can implement a wheel group easily.
(And yes, I'm guilty of discriminating against many users: "www-data", "nobody", "mail"...)
Where is this stated? All I see is that /usr/bin/passwd has a local root vulnerability; to me, that says that if I can exploit a buffer overflow in any arbitrary program, even an unprivileged one, I can get root on the box.
You've conveniently removed what I wrote: This is true on any *NIX system, there are tons of vulnerabilities which allow attackers who can execute code under a non-root UID to obtain root access.
It doesn't matter if you fix passwd(1). There are too many other issues, most of which still have to be discovered. You can't rely on local *NIX security, you have to use other means to stop attackers. For example, one widely-used approach is "one machine per service" or "one machine per trust domain".
. . . and this is "medium"?
Yes, because prior authentication is required. Local security on *NIX is known to be rather weak, and only the clueless rely on it for critical applications.
There's also a tool from Microsoft.
There are some issues with that tool, though. A safe option is plain ASCII export.
Currently, PDF export is also a possibility, but this might change in the future, as PDF evolves. Just keep in mind that when redacting a PDF document, it's not sufficient to paint black rectangles over the critical parts.
George thinks he'll make enough money off of Episode III and the upcoming Star Wars DVD Set.
No, he doesn't think that. Otherwise, why would he care about a Sam & Max sequel for which he cannot recoup the development costs?
(To be honest, I doubt that he's involved at all with the gaming division. Isn't it mostly dead anyway?)
This computer reminds me of a Mercedes-Benz S-Klasse four-seater which was so heavy that only two people were allowed to drive in it. And you mustn't put anything into the rear trunk, of course.
What would really be interesting is how many people have their own web page(s).
13 percent, according to the survey. This number still looks rather high, though.
When was the last time you heard about a public-sector IT project that succeeded?
According to the most pessimistic estimates, 30% of all public-sector IT projects succeed.
BelWue, the regional research network over here, is doing rather fine, for example.
Linux or no, it seems like pretty much every IT investment made by any government (maybe it's just the UK?) ends up becoming a steaming pile of failure that gets reported ten-times overbudget, 8 years late, and eventually gets either scrapped or audited (those being essentially the same)
What about the national do-not-call list in the US? I haven't heard of any technical problems, but it surely was (and is) a technical challenge to run it.
The problem with good, complex IT is that it stays in the background. You won't notice it until it breaks. Well-working systems aren't newsworthy.
Will Microsoft publicise the news worldwide, and show that it was completely the fault of trying to use non-Microsoft software?
I wouldn't start a war on this front because it's pretty unsafe terrain. You can't be sure that none of your own failures suddenly dominate the discussion.
but I don't get why they would owe the us-taxpayers anything.
Oops. I wanted to write "to us, the taxpayers". I'm sorry for the germanism.