Look, this bloke admits to being a crook: he claims he's expecting to be *paid* for finding vulnerabilities, whether by Apple or by some unknown sponsor. He's made exceptional claims about he nature of the flaw he's unearthed, implying that there's a deep flaw in mDNSresponder that Apple will not fix, but he refuses to notify Apple until some payment he's expecting is completed.
Either he's a crook *and* he's undermining his sponsor, or it's a hoax. Even if the alleged death threats aren't part of the hoax, there's no reason to assume they're not from the the guy he claims paid for the research and farm of 1500 Macs to test it on.
Now we have unverified claims of death threats to add credibility to unverified claims of worms attacking a deep flaw in mDNSresponder... a flaw so subtle that Apple wouldn't be able to fix it without the help of said anonymous researcher who's allegedly received death threats over it.
Now this could all be true, but then SCO could really have thousands of lines of Linux code copied from UNIX they're still hiding so they can bring it out in a dramatic eleventh-hour release and snatch victory from the jaws of defeat.
I don't doubt that there's flaws in mDNSresponder. I don't doubt that you could write a worm to exploit them. I don't doubt that Apple is capable of fixing one symptom of a flaw rather than the cause... they've done it before. But there's nothing new here... schemes like Rendozvous/Bonjour/Zeroconf and the superficially similar "Universal Plug and Play" in Windows are a compelling target for potential attacks and have been criticized in the past. They're not needed for the normal operation of the system, and should be disabled unless you actually know you need them and are on a known secure LAN... and recipes and utilities for disabling both have been around for years.
But there is no way that any legitimate security professional would proceed in the manner that the people alleged to be involved in have been behaving over the past several months. The whole presentation of this affair seems almost designed to discredit the security community in the public eye.
Notify Apple, then release the details. There's no other ethical course of action.
In which a Slashdot article is directed through a hlaf-silvered mirror. On one path it may interact with a reader. If the reader is a dud, its quantum state (and head) collapses. Otherwise, its head explodes. By measuring the comments on the article at a site where the reader has not yet read it, we can determine if the article makes the reader's head explode or not without actually exploding it.
Also, from TFA: "If this experiment we're doing works, then I will follow up and push it as hard as possible. And if it doesn't work, I will write a science-fiction novel where it does work," he said. "It's a win-win situation."
By allowing more volume, reducing lines, decreasing the amount of people involved in the voting process [...]
And how do you imagine that replacing a punch card or a paper form with a touch screen does that?
If the polling stations cost more, there are fewer of them, which means longer lines.
If the poll equipment is more complex, the qualifications required for the poll workers increase, which means fewer are available, which means fewer polling places and longer lines.
Still through, for something like printer drivers (which you'll presumably want to be installed system-wide), installing to home isn't a very good solution IMHO.
Why not? Printer "drivers" are application configuration files and user level filters. There's no kernel involvement. If you installed OpenOffice in ~, why not install the drivers there?
In addition, there's no reason *anything* in the printer toolchain should need to be setuid root.
And there's no reason any installer should be changing anything anywhere but in its own files, let alone changing the permissions on applications.
If you allow the local user to install programs, then the local user is either; a) going to need write access to all the usual locations (either/usr/bin and/usr/lib, or/opt) which wouldn't solve the problem TFA is on about b) going to need to use some middleware that *does* have rwx access to/usr and a fine grained ACL system dictacting which users have access to what
c) Going to have to install the software to some place like ~/bin and ~/lib, as you're supposed to do in a multi-user system if you're not the system administrator, and as people always used to do back when all this stuff was designed.
It suids the apps temporarily, and improperly un-suids them.
OK, I read this message, and I can't understand why on earth any software would need to, even temporarily, set the setuid bit on anyone else's software. What's the purpose of this action?
From the things I read, Mac OS X is just as vulnerable and dangerous as Windows.
You need to read deeper.
OSX: No routed open ports by default. All services can be bound to localhost only. All IP-based services can be disabled. Conventional browser that requires applications to install extensions. Can be run securely with no firewall in place, the optional firewall is "defense in depth". It's not perfect, but the "surface area" exposed to remote attacks is small and can be eliminated.
Windows: Routed open ports by default, most services are promiscuous, and some listening services are required for normal operation of the OS. Browser built around embedded code, and the ability to run remotely provided embedded code can not be removed without disabling the browser and parts of required utilities. Firewall is enabled by default because it's required to close *most* direct remote attacks (but not all, and not attacks through the HTML control). Even with the firewall in place Windows has a larger surface area to exploits than any other OS in use, and you can't eliminate it without disabling basic OS functionality.
If this vulnerability and unreleased experimental software counts as a "major virus or worm" then the AOL trojan horse (which actually reached the wild) does as well.
Even assuming he hasn't made up that bit, I'm sure some of the real, ethical researchers looking at the mDNSresponder source code right now will figure out what he's hinting at.
The "Internet Worm" targeted Sendmail. Which has proceeded to become notorious for security holes.
The biggest UNIX webserver security holes are due to PHP.
The biggest problem is not "closed" vs "open" source. It's design. Is the API secure (that is, if the implementation is perfect, would the resulting system be perfectly secure)? Does the API fail "open" or "closed"? Is there a mechanism to request trusted access from *outside* the trusted domain? If so, is that enabled by default?
If the answers are "yes", "closed", "no", and "no" then you may have built a secure system.
Surprise, surprise, there's a lot of open source software that isn't secure by that standard, including the much-lauded Firefox. Now don't get me wrong, the surface area Firefox's XPI and the XPI install mechanism exposes to attack is like the radar signature of a stealth fighter, where Internet Explorer's "insecurity" zones and ActiveX give it the radar signature of a flock of 747s, but it's not necessary for either exposure to exist at all.
Open Source doesn't create secure systems. It's a hell of a mitigating factor, yes, but the real source of long-lasting security holes (and we don't know if this is one or not, because the soi-disant "researcher" responsible isn't being open about the vulnerability he's found) is insecure design and a preference for patching particular attack vectors rather than fixing the insecure design. And that isn't limited to closed source systems.
Those features require a more powerful processor, more RAM, a higher resolution display in the case of the camera, physical space inside the case for the camera and lens that can't be used for the battery, and so on. Even if you don't use the features, they still cost you in battery life.
And all the complexity is still there if you don't use it as well.
The only way to get a simple phone with long battery life is to build a phone designed for simplicity and minimal features. There's no other way.
I don't run virus checkers on Windows unless I know the machine's going to be exposed to mundanes or other sources of bad karma. They are *all* abominable pieces of crap... this has nothing to do with whether the OS is multi-tasking, multi-threading, preemptive, or anything else... it has to do with the antivirus itself being a bottleneck. Every antivirus software as far as I can tell just traps whatever random API it feels like, and it locksteps all calls to all APIs it traps by blocking them on its "engine"... which is just a fancy "grep" as far as I can tell.
The security problems in Windows that make antivirus so necessary are a real problem with the OS, but that's got very little to do with the original article. BeOS may or may not have ended up with major security problems, I don't know. It might have... it's so easy to integrate applications with the Tracker that it would just take a sufficiently popular webbish application deciding to take advantage of that and screwing up to make it a big problem.
Abuse any system and it WILL break, eventually. BeOS was particularly sensitive to memory shortfalls, for example. It didn't take much paging activity to make it grind to a halt, even right up to the end.
A change to a library routine that's used to read an image file is a change to a library routine that's used to read an image file.
It is *more* likely that this will effect "all your software" if it's a change in a commonly used component than if it's in a component that just happens to be part of a runtime for a language that some of your software uses.
Also, I wrote "Yes, the vendor could sneak in other patches, but that's no different to *any* other patch from *any* vendor that provides a language runtime". I didn't mean "any patch to a language runtime" from such a vendor, I mean *any* patch from such a vendor.
For example, *any* patch from Microsoft might change MSVCRT, so you shouldn't casually roll out *any* patch from Microsoft lest it break every program written in Visual C.
I'm saying that any patch that is going to affect diverse development teams' work, across the entire organization is going to have to go through an expensive rollout process, and that's the unfortunate reality that people in large enterprises have to live with
That means, *any* patch from *any* vendor that makes *any* software that your developers are likely to depend on, whether it's a patch for that software or not, is a "patch that is going to affect diverse development teams' work". Any of them.
So DO you roll out security fixes at all? How do you justify it?
the whole Windows desktop usually locks-up if you have one operation in progress and you try and start another operation, even under Vista.
I think the main reason is that this isn't actually true.
While I should be the LAST person to be defending Windows, I've gotta call you on this ludicrous exaggeration. Yes, Windows 3.x and Windows 9x were horrible, but I can't recall the last time I could say the "whole Windows desktop" has locked up on me on any modern (NT-based) Windows.
That was my experience, too. If you were used to Windows 3.1 or Windows 9x, BeOS looked phenomenal. If you were used to real operating systems (even ones as simple as AmigaOS, let along the systems Be was competing with in the '90s) it was nothing exceptional.
Slashdot Mirror
Look, this bloke admits to being a crook: he claims he's expecting to be *paid* for finding vulnerabilities, whether by Apple or by some unknown sponsor. He's made exceptional claims about he nature of the flaw he's unearthed, implying that there's a deep flaw in mDNSresponder that Apple will not fix, but he refuses to notify Apple until some payment he's expecting is completed.
Either he's a crook *and* he's undermining his sponsor, or it's a hoax. Even if the alleged death threats aren't part of the hoax, there's no reason to assume they're not from the the guy he claims paid for the research and farm of 1500 Macs to test it on.
Sheesh.
... and recipes and utilities for disabling both have been around for years.
Now we have unverified claims of death threats to add credibility to unverified claims of worms attacking a deep flaw in mDNSresponder... a flaw so subtle that Apple wouldn't be able to fix it without the help of said anonymous researcher who's allegedly received death threats over it.
Now this could all be true, but then SCO could really have thousands of lines of Linux code copied from UNIX they're still hiding so they can bring it out in a dramatic eleventh-hour release and snatch victory from the jaws of defeat.
I don't doubt that there's flaws in mDNSresponder. I don't doubt that you could write a worm to exploit them. I don't doubt that Apple is capable of fixing one symptom of a flaw rather than the cause... they've done it before. But there's nothing new here... schemes like Rendozvous/Bonjour/Zeroconf and the superficially similar "Universal Plug and Play" in Windows are a compelling target for potential attacks and have been criticized in the past. They're not needed for the normal operation of the system, and should be disabled unless you actually know you need them and are on a known secure LAN
But there is no way that any legitimate security professional would proceed in the manner that the people alleged to be involved in have been behaving over the past several months. The whole presentation of this affair seems almost designed to discredit the security community in the public eye.
Notify Apple, then release the details. There's no other ethical course of action.
In which a Slashdot article is directed through a hlaf-silvered mirror. On one path it may interact with a reader. If the reader is a dud, its quantum state (and head) collapses. Otherwise, its head explodes. By measuring the comments on the article at a site where the reader has not yet read it, we can determine if the article makes the reader's head explode or not without actually exploding it.
Is this the "Einstein's Bridge" John Cramer who's proposing this test?
:)
If you follow the link from the article you'll see the answer.
Also, from TFA: "If this experiment we're doing works, then I will follow up and push it as hard as possible. And if it doesn't work, I will write a science-fiction novel where it does work," he said. "It's a win-win situation."
By allowing more volume, reducing lines, decreasing the amount of people involved in the voting process [...]
And how do you imagine that replacing a punch card or a paper form with a touch screen does that?
If the polling stations cost more, there are fewer of them, which means longer lines.
If the poll equipment is more complex, the qualifications required for the poll workers increase, which means fewer are available, which means fewer polling places and longer lines.
If you mean the RTM worm, it primarily targeted fingerd not sendmail.
:)
Since pretty much everyone with the source to sendmail had the source to fingerd as well, I'm kind of missing your point here.
The good thing about electronic voting is it allows more voters
Um, how do you imagine that might happen?
The reasons people don't vote include things like not wanting to be on Jury rolls, and the time it takes to get to the voting place.
How does having a touch screen instead of a punch card make a difference?
(no, "electronic voting" is not "internet voting"... the problems there are a whole different kettle of wardheelers)
Still through, for something like printer drivers (which you'll presumably want to be installed system-wide), installing to home isn't a very good solution IMHO.
Why not? Printer "drivers" are application configuration files and user level filters. There's no kernel involvement. If you installed OpenOffice in ~, why not install the drivers there?
In addition, there's no reason *anything* in the printer toolchain should need to be setuid root.
And there's no reason any installer should be changing anything anywhere but in its own files, let alone changing the permissions on applications.
The media is very good at taking a word and giving their own spin to it. Thus hacker gets a negative connotation.
Which is why it's a useful filter. It tells you that the person you're speaking to gets their ideas about computer security from the media.
If you allow the local user to install programs, then the local user is either; /usr/bin and /usr/lib, or /opt) which wouldn't solve the problem TFA is on about /usr and a fine grained ACL system dictacting which users have access to what
a) going to need write access to all the usual locations (either
b) going to need to use some middleware that *does* have rwx access to
c) Going to have to install the software to some place like ~/bin and ~/lib, as you're supposed to do in a multi-user system if you're not the system administrator, and as people always used to do back when all this stuff was designed.
It suids the apps temporarily, and improperly un-suids them.
OK, I read this message, and I can't understand why on earth any software would need to, even temporarily, set the setuid bit on anyone else's software. What's the purpose of this action?
If some white guy starts casually using terms like "nigger" you know something useful about them: they're an idiot racist.
The word "hacker" is a similarly useful filter.
From the things I read, Mac OS X is just as vulnerable and dangerous as Windows.
You need to read deeper.
OSX: No routed open ports by default. All services can be bound to localhost only. All IP-based services can be disabled. Conventional browser that requires applications to install extensions. Can be run securely with no firewall in place, the optional firewall is "defense in depth". It's not perfect, but the "surface area" exposed to remote attacks is small and can be eliminated.
Windows: Routed open ports by default, most services are promiscuous, and some listening services are required for normal operation of the OS. Browser built around embedded code, and the ability to run remotely provided embedded code can not be removed without disabling the browser and parts of required utilities. Firewall is enabled by default because it's required to close *most* direct remote attacks (but not all, and not attacks through the HTML control). Even with the firewall in place Windows has a larger surface area to exploits than any other OS in use, and you can't eliminate it without disabling basic OS functionality.
Or if it is, the AOL trojan counts.
If this vulnerability and unreleased experimental software counts as a "major virus or worm" then the AOL trojan horse (which actually reached the wild) does as well.
Don't count your money yet.
Even assuming he hasn't made up that bit, I'm sure some of the real, ethical researchers looking at the mDNSresponder source code right now will figure out what he's hinting at.
The "Internet Worm" targeted Sendmail. Which has proceeded to become notorious for security holes.
The biggest UNIX webserver security holes are due to PHP.
The biggest problem is not "closed" vs "open" source. It's design. Is the API secure (that is, if the implementation is perfect, would the resulting system be perfectly secure)? Does the API fail "open" or "closed"? Is there a mechanism to request trusted access from *outside* the trusted domain? If so, is that enabled by default?
If the answers are "yes", "closed", "no", and "no" then you may have built a secure system.
Surprise, surprise, there's a lot of open source software that isn't secure by that standard, including the much-lauded Firefox. Now don't get me wrong, the surface area Firefox's XPI and the XPI install mechanism exposes to attack is like the radar signature of a stealth fighter, where Internet Explorer's "insecurity" zones and ActiveX give it the radar signature of a flock of 747s, but it's not necessary for either exposure to exist at all.
Open Source doesn't create secure systems. It's a hell of a mitigating factor, yes, but the real source of long-lasting security holes (and we don't know if this is one or not, because the soi-disant "researcher" responsible isn't being open about the vulnerability he's found) is insecure design and a preference for patching particular attack vectors rather than fixing the insecure design. And that isn't limited to closed source systems.
Those features require a more powerful processor, more RAM, a higher resolution display in the case of the camera, physical space inside the case for the camera and lens that can't be used for the battery, and so on. Even if you don't use the features, they still cost you in battery life.
And all the complexity is still there if you don't use it as well.
The only way to get a simple phone with long battery life is to build a phone designed for simplicity and minimal features. There's no other way.
Um did you even bother to look around or read?
Did you? One of the main issues was battery life, another complexity.
I don't know if they have a camera or mp3 player on them, but who cares if they do?
Someone looking for better battery life and less complexity.
MS conceded to letting Office users run the software at home as well.
They used to do that as a matter of course. For the same reason they're doing it again, because it blocks the competition.
I don't run virus checkers on Windows unless I know the machine's going to be exposed to mundanes or other sources of bad karma. They are *all* abominable pieces of crap... this has nothing to do with whether the OS is multi-tasking, multi-threading, preemptive, or anything else... it has to do with the antivirus itself being a bottleneck. Every antivirus software as far as I can tell just traps whatever random API it feels like, and it locksteps all calls to all APIs it traps by blocking them on its "engine"... which is just a fancy "grep" as far as I can tell.
The security problems in Windows that make antivirus so necessary are a real problem with the OS, but that's got very little to do with the original article. BeOS may or may not have ended up with major security problems, I don't know. It might have... it's so easy to integrate applications with the Tracker that it would just take a sufficiently popular webbish application deciding to take advantage of that and screwing up to make it a big problem.
Abuse any system and it WILL break, eventually. BeOS was particularly sensitive to memory shortfalls, for example. It didn't take much paging activity to make it grind to a halt, even right up to the end.
What's next, force conventional radio to switch to DRM-encumbered PCM?
Your other post refers to Windows XP.
If your system has been so messed up that you can't tell if it's 2000 or XP, I suspect you might want to reinstall.
You're still creating an artificial distinction.
A change to a library routine that's used to read an image file is a change to a library routine that's used to read an image file.
It is *more* likely that this will effect "all your software" if it's a change in a commonly used component than if it's in a component that just happens to be part of a runtime for a language that some of your software uses.
Also, I wrote "Yes, the vendor could sneak in other patches, but that's no different to *any* other patch from *any* vendor that provides a language runtime". I didn't mean "any patch to a language runtime" from such a vendor, I mean *any* patch from such a vendor.
For example, *any* patch from Microsoft might change MSVCRT, so you shouldn't casually roll out *any* patch from Microsoft lest it break every program written in Visual C.
I'm saying that any patch that is going to affect diverse development teams' work, across the entire organization is going to have to go through an expensive rollout process, and that's the unfortunate reality that people in large enterprises have to live with
That means, *any* patch from *any* vendor that makes *any* software that your developers are likely to depend on, whether it's a patch for that software or not, is a "patch that is going to affect diverse development teams' work". Any of them.
So DO you roll out security fixes at all? How do you justify it?
the whole Windows desktop usually locks-up if you have one operation in progress and you try and start another operation, even under Vista.
I think the main reason is that this isn't actually true.
While I should be the LAST person to be defending Windows, I've gotta call you on this ludicrous exaggeration. Yes, Windows 3.x and Windows 9x were horrible, but I can't recall the last time I could say the "whole Windows desktop" has locked up on me on any modern (NT-based) Windows.
That was my experience, too. If you were used to Windows 3.1 or Windows 9x, BeOS looked phenomenal. If you were used to real operating systems (even ones as simple as AmigaOS, let along the systems Be was competing with in the '90s) it was nothing exceptional.