Indeed, but the issue with Halo 2 is whether its popularity is enough to propel DX10/Vista. I don't think it is, primarily due to the success of the Xbox 360, which could be a much cheaper solution to playing the game than upgrading your computer. Plus, you don't have to deal with Vista. And many of the people who were going crazy for Halo 2 didn't want to wait.
I just don't think that Halo 2 will be the driving force behind Vista upgrades.
"Beta" in some cases, now just means "Hey, we don't have the resources to dedicate 2 man-years of testing for this App, but it works ok for us". That's exactly what the grandparent was saying. "Beta" used to mean WARNING! DO NOT TOUCH! DO NOT USE IN PRODUCTION!. Then Google used it the term (by your definition) in a number of applications, raising the general expectation of beta software.
At least, that's what the grandparent meant, I'm sure. But I also imagine that his tongue was in his cheek.
The ones who complain are the ones who have hardware not found on this list: http://live.gnome.org/NetworkManagerHardware If yours is working fine, it's because your network card is supported. *ahem*
I tried switching to Network-manager in Ubuntu 6.10. Quite simply, it failed. I have an Intel Pro Wireless 2200 (which is, in fact, on that list).
I may try the Feisty LiveCD just to see if things have improved.
I'm a Unix geek (Linux on the desktop, FreeBSD on the server) and actually, the Expose-like features in Beryl interest me greatly. I already use multiple-desktops, and the cube, while neat, is like most of the other effects--just eye candy. But Expose is useful, particularly for low-resolution displays, and is one of the reasons I've been considering getting a Macbook Pro. Having used the feature, it impresses me that much.
Some of the other OS X effects do have uses, though. Bouncing on the dock is a pretty good means of notification, particularly for people who notice motion more than color- or shape-changes. I don't know if there's anything like this in Beryl, since it may be highly dependent upon the desktop environment, rather than the window manager.
While all this is true, you just can't ignore the market. It will be awhile before Vista becomes mainstream. In the meantime, companies have two choices regarding DX: using DX9 (and aging technology) or DX10 (and reducing their potential market, since not everyone has Vista or can afford a computer capable of running it).
Microsoft has to cater to both developers and users. It's kinda like the chicken-and-egg problem--how do you get users to upgrade to Vista if there's no incentive? How do you get developers of 3rd party software to create that incentive (we'll ignore the Halo franchise, for the moment). We'll probably see Microsoft backport DX10 to some degree before too long just to get developers to start writing for it. Once they do, Microsoft will halt development on DX10 for XP in order to compel the users to upgrade (since porting software from DX10 to DX9 will be more than many companies can afford to do.) Then, Microsoft wins, as users accustomed to being able to run games find that they have lost that ability.
I agree in general, but for the sake of argument, couldn't GHB possibly be transported in a soap bottle? Even transported in actual soap, and then extracted later?
Because it's a pain in the ass, and the RIAA has been wrong before? Because even if you don't have anything to hide, there's something creepy about a stranger reading your mail? Because there's a thing called 'privacy' which we used to hold dear, but which is slowly being eroded by the corporate government?
Yeah. Sure is strange that you haven't used your computer/at/all/ in a way that would modify timestamps in the past 6 years. Or that those service packs that weren't even out 6 years ago still bear that timestamp.
It's an absurd argument. Everything is copywritten the moment that it is placed in a tangible form. Yet there is plenty of precedent for getting copies of documents which may be relevant to a court case. You can try to fight the hundreds of years of case law. Good luck with that.
Write your passwords down, and keep them in a safe. Seriously.
I have a number of passwords that I use so infrequently that I basically go through the password-reset procedure each time I need to access the site. This doesn't work for sites whose password-reset procedure includes so-called "security questions" (which are secure from generic hacking, but pretty easy to defeat if you're being targeted) because I type gibberish into these. It's pretty irritating, but the worst I've ever had to do is re-calculate the taxes that I'd saved but not submitted.
Using the safe method works well enough, though. It's not as convenient, but any password that I use with any regularity gets ingrained in my muscle-memory quickly enough.
All too true. The matter of trust is certainly important, because without it, you might as well not use a computer! There are certainly different levels of trust, though, and for someone in a security-sensitive government office, the trust bar really needs to be raised. These are people who absolutely should audit every piece of code that touches the computer.
Sill it is most unlikely a black-hat would give out source with a payload since it is too easy to get found out and possibly traced. It depends upon what they have to gain, their location, etc. A foreign hacker attempting to compromise government security might have less to fear. Of course, this would not be a commonly used tactic--even a foreign hacker would never be trusted again, and would have to change his identity and build up trust all over again.
For a cracker a binary is much safer and it is even more safer if delivered by a bot or email. Putting malicious code in a repository is risky for the cracker but this does not mean that they won't do it so for the person who downloads a binary from a site the risk even though small is always there. Managing risk is hard. Certainly, unless I was expecting it, I would never run code received through e-mail without examining it. Compromising the repo? Harder, but not impossible.
What makes MS Windows a problem is that while it can be reasonably a secure environment if you know what you are doing most people don't and set themselves up with administrator privileges so that a bad program will cause enormous problems. Though you can do a lot of bad things without administrator privileges. In some cases, you might need escalated privileges in order to spoof security protocols (Vista's security) or create hooks to capture encrypted traffic (we've seen some spyware do this to watch https traffic), but in general, a non-admin process can read any file that the user can read and can open network connections to send that information back to the enemy. It could also spam and try to infect other machines through many different network-based vectors. Administrator-by-default is bad, but I don't think that it's the gaping security hole that everyone makes it out to be.
To sum up the most important thing a user can do do to protect themselves is to become more educated with regard to using a computer I absolutely, 100% agree. And I'm not looking for everyone to become an expert, but they just shouldn't trust everything that comes across that wire. This goes double for people in security-sensitive positions.
Well, I know windows uses Mapi calls and such for communication between programs. Yes, I couldn't remember the name for it, but I believe that is correct. The standard communication and controls (text boxes, list boxes, etc.) are definitely one piece of the puzzle that is the history of Windows security flaws.
Note: most of the below is speculation intermixed with facts. When Windows was originally created, there wasn't much thought given to security in this case--and probably with good reason. Back then, the issues for home PCs were largely viruses and trojans, not the self-spreading worms that we see today. The massive interconnectedness of today's computers probably wasn't expected, and viruses/trojans passed on floppy disk don't need a buffer overflow to spread.
So time passes, and Microsoft chooses to maintain as much backwards compatibility as possible between revisions of Windows...the Internet starts creeping up...Windows uses lots and lots of insecure, legacy code in newer versions, and all of a sudden, broadband starts becoming the norm, and every Windows computer on the Internet becomes a new vector of infection. All those controls which used to be in non-connected programs get tossed into Internet Explorer, and blammo--security hell. A few revisions later, and you get Windows XP SP2, which contained some measure of protection, and then Vista, in which much of the underlying support code got rewritten. We'll see whether it's actually all that it's cracked up to be, I guess.
Wait, you don't read them? Here I've got some software for you to install, trust me. I do read them, but almost no one else seems to. I've posed that question hundreds of times to various people, and you're probably the fourth or fifth one to actually claim to do so much as even spot-check the files.
Ok, the onus is on you to demonstrate how a buffer overflow in emacs that occurs via loading a text file into a buffer can trigger the kind of effect reported via Word. Unless you're looking for an actual overrun in Emacs, what you're asking for isn't hard. From the article: By opening the document, the employee activated hidden software commands establishing what Reid described as backdoor communications with the hackers.
I take "hidden commands" to mean shellcode. The other possibility, a macro that auto-runs, wouldn't really require a patch to disable--it would only require changing a preference. Also, I think auto-running macros have been disabled by default for years, but I don't have anything to back that statement up.
So now we look at the payload--establishing backdoor communications with the hackers. How is this difficult? Trojans have been capable of doing this for years. It doesn't take much to start a daemon that queries a control server, listen for commands, and execute them.
The only thing left is the actual buffer overflow. If you're actually suggesting that Emacs is incapable of having a buffer overflow, that's an assertion I'd like to see a basis for, and is largely irrelevant since it was just an example. If you're asserting that OSS cannot have buffer overflows, then you're truly delusional. I was refuting the statement, "The fact that a simple Word document can cause such a big problem is really sad." Any exploitable buffer overflow is going to rely, in some way, on malicious user input. Any program which reads user input should be wary of the buffer overflow. This includes text editors.
Or they embedded a regex or other code to look for the exact overflow and drop it instead of eliminating the overflow. Not that they've done anything like that before, right? Your attitude seems a bit hostile. I'm not trying to make any statement about the validity or correctness of their patch. That there was a patch implies that there was, indeed, something to patch. I used that plus other statements from the article to conclude that it was probably one of two vulnerabilities.
I don't know if you're a Linux zealot, a Microsoft hater, or both, but there's room for civility in discussions like this. I'm typing this from my personal notebook which only runs Linux. I don't use Windows for anything more than I am required by my job. That said, I recognize that security isn't just about what OS you run. I love Linux, but I also recognize the fact that there have been vulnerabilities in FOSS, and you can never forget the human factor (a trojan'd binary/script in Linux could do as much damage as one on Windows).
I think that Emacs could be exploited to the same degree. There are a number of reasons that I don't think it has been.
Windows has more users, and less clueful users, so exploits will stick around.
There's a huge repository of exploit code for Windows. HUGE. Check out Metasploit sometime, if you don't already know about it.
Windows machines are less likely to be mission-critical, and so less likely to be monitored to the same degree as Unix machines.
Windows monoculture means that the shellcode is easier to get working. A slightly different kernel or libc version on Linux would render the exploit moot.
My mention of Outlook was because there's some functionality in Windows to send mail using the settings you've set up in Outlook, including username/password, proxy, port, server, etc. This means that a spambot can still send spam, even if port 25 is ACL'd off or the remote SMTP server requires authentication (assuming the user saved their password). Yeah, it's a Windows thing in this case, but mere exploitation of the system is not.
Ok now we are getting into compiling source code and this is not what an normal user would do, even under Unix or Linux much less MS Windows. I can and do on occasions but normally try to get an "rpm" kit (Linux) but I can compile from source. I was trying to illustrate a point. Rather than suggesting that these are vectors of attack that we should be wary of, I was pointing out that even Linux/Unix power users put a lot of trust in things. It's just just a concern for people using Microsoft--though blackhats are more likely to target Microsoft due to the marketshare.
On Linux/Unix when I get source I always work as a non privileged user (myself). First I read the README then after setting up any parameters and/or environmental variables I run./configure and normally make, after which I test the program(s) and then only when I am satisfied tat everything works as it is supposed to will I install the software, even then I will normally only allow installation in/usr/local. How do you enforce that last restriction? Using the very Makefile that you didn't read through? And since you're writing to that directory, I imagine you're running that last bit with sudo?
I normally only get source from reputable sites such as Freshmeat and Sourceforge, however for Linux I normally get rpm's from reputable repos. I always check the the source or rpm against it's check-sum. Basically I never install binaries from a non trusted site. And for most people, yeah, that's very reasonable. We have neither the time nor inclination in most cases (and for many people the capability, either!) to audit the files. But that's the point, really. Someone could compromise the repo or the account of the project maintainer at Sourceforge. Someone could try a long con of gaining trust before putting in a malicious, if innocuous, bug in their 70th submitted patch.
And just because anyone can look at the code doesn't mean that anyone does.
While it is possible to get source for MS Windows programs, compiling it can be a nightmare although this depends on the skills of the person and the compiler used. In the majority of cases many people just download a "setup.exe' and run it. Of course this means that you completely trust the site and the download without any possibility of seeing the source code. But people do this with Linux and OSS all the time. They feel safer knowing that the code could be audited, but in reality, how often does anyone audit the code?
The buffer overflow would presuambly allow the trojan to execute any commands that the user could execute. If the user was running as Administrator (not stated in the article) then yes, it would gain control of the machine. If not, the trojan could read any file that the user could read, connect to any site that the user could connect to, send mail through the DLLs that Outlook uses, etc.
The article was short on details. The only thing in it that even hints at escalated privileges was the "tunnelling through the firewall" doubletalk, which, in my mind, means that it detected a proxy and used it.
This particular example is rather silly; however even if it were the case for the sake of argument, it's not the same: exploiting a buffer overflow in emacs as a regular user will not give you root access to the system. *sigh* I really hate this argument because it's so damned pointless. Network operations aren't privileged in any OS I happen to use (BSD, Linux, and rarely, Windows). I can make a connection to any random address without escalating, and I can even listen for connections on ports > 1024. File I/O operations aren't privileged in any OS I use. There are ACL/permission issues regarding which files I may access, but for those which I have access to, I may generally do whatever I please with the files.
That's all a trojan needs in order to steal data. Oh yes, it'd be handy to be able to hide and cover your tracks, and that almost certainly will require high privileges, but it's not necessary in order to do nasty things. A Linux trojan could still create a spambot that took orders from IRC or the web. It could even hide (to some degree) from the user it is running as (do you type/bin/ls or do you allow your path to determine the binary which is run?).
In the specific case of the State Dept, the intrusion was discovered very quickly. I read the article and don't recall them specifying that the privileges were escalated, and they also didn't mention whether or not the user was running as Administrator. Your assumptions aside, a malformed text file opened in emacs could have done the same damage as was mentioned in the article.
Sourceforge has been compromised at least once in recent memory, and you're still trusting that the project maintainer isn't doing something nasty.
Anyway, the crux of the issue is that we make choices based upon convenience. We open Word documents from unknown senders because we are expecting invoices. We run./configure and make because we trust them. Actually, the latter example would be easier to exploit, as it is explicitly running commands (whereas a Word document isn't expected to do so). The State department should not be opening documents from untrusted resources without performing some sort of verification on them, first. I don't care whether that verification is running them through antiword, opening them on computers in a DMZ, or what. Anything coming from the outside should be considered tainted until closely examined.
I think most of the other comments refuted you just fine, but I did want to point out one thing:
Even if it had any buffer overflows, the problem would not be exploitable from remote systems. The article explicitly stated that the employee had received an e-mail containing a Word document. They opened the word document. This is all the attacker needs to exploit "from remote systems", if there was indeed a buffer overflow. Whatever shellcode was embedded in the file would take over and be capable of performing the network actions.
Runing./configure or make or make install could cause just as large a problem. Do you read through those scripts before running them?
Furthermore, buffer overflows could exist in just about any program. There could be one in emacs right now, triggered by reading a file into the buffer. Then it would be "scary.. The fact that a simple text file can cause such a big problem is really sad."
Unfortunately, they didn't disclose the nature of the vulnerability. "hidden software commands" in the mass media could be anything from shellcode to an executable embedded in the document, to a macro. Since Microsoft patched it, it was probably either something that autoran or an overflow.
Slashdot Mirror
Indeed, but the issue with Halo 2 is whether its popularity is enough to propel DX10/Vista. I don't think it is, primarily due to the success of the Xbox 360, which could be a much cheaper solution to playing the game than upgrading your computer. Plus, you don't have to deal with Vista. And many of the people who were going crazy for Halo 2 didn't want to wait.
I just don't think that Halo 2 will be the driving force behind Vista upgrades.
At least, that's what the grandparent meant, I'm sure. But I also imagine that his tongue was in his cheek.
Are you using the open source nv driver, or the binary driver from Nvidia?
I tried switching to Network-manager in Ubuntu 6.10. Quite simply, it failed. I have an Intel Pro Wireless 2200 (which is, in fact, on that list).
I may try the Feisty LiveCD just to see if things have improved.
I'm a Unix geek (Linux on the desktop, FreeBSD on the server) and actually, the Expose-like features in Beryl interest me greatly. I already use multiple-desktops, and the cube, while neat, is like most of the other effects--just eye candy. But Expose is useful, particularly for low-resolution displays, and is one of the reasons I've been considering getting a Macbook Pro. Having used the feature, it impresses me that much.
Some of the other OS X effects do have uses, though. Bouncing on the dock is a pretty good means of notification, particularly for people who notice motion more than color- or shape-changes. I don't know if there's anything like this in Beryl, since it may be highly dependent upon the desktop environment, rather than the window manager.
While all this is true, you just can't ignore the market. It will be awhile before Vista becomes mainstream. In the meantime, companies have two choices regarding DX: using DX9 (and aging technology) or DX10 (and reducing their potential market, since not everyone has Vista or can afford a computer capable of running it).
Microsoft has to cater to both developers and users. It's kinda like the chicken-and-egg problem--how do you get users to upgrade to Vista if there's no incentive? How do you get developers of 3rd party software to create that incentive (we'll ignore the Halo franchise, for the moment). We'll probably see Microsoft backport DX10 to some degree before too long just to get developers to start writing for it. Once they do, Microsoft will halt development on DX10 for XP in order to compel the users to upgrade (since porting software from DX10 to DX9 will be more than many companies can afford to do.) Then, Microsoft wins, as users accustomed to being able to run games find that they have lost that ability.
I agree in general, but for the sake of argument, couldn't GHB possibly be transported in a soap bottle? Even transported in actual soap, and then extracted later?
In the context of a court case, I would imagine so. At the same time, you'd have to prove that they listened to it, and that would be difficult.
But Windows might leave traces of the mounted drive.
Because it's a pain in the ass, and the RIAA has been wrong before? Because even if you don't have anything to hide, there's something creepy about a stranger reading your mail? Because there's a thing called 'privacy' which we used to hold dear, but which is slowly being eroded by the corporate government?
Yeah. Sure is strange that you haven't used your computer /at/all/ in a way that would modify timestamps in the past 6 years.
Or that those service packs that weren't even out 6 years ago still bear that timestamp.
It's an absurd argument. Everything is copywritten the moment that it is placed in a tangible form. Yet there is plenty of precedent for getting copies of documents which may be relevant to a court case. You can try to fight the hundreds of years of case law. Good luck with that.
Yes, you're right, you win. Good day to you.
Write your passwords down, and keep them in a safe. Seriously.
I have a number of passwords that I use so infrequently that I basically go through the password-reset procedure each time I need to access the site. This doesn't work for sites whose password-reset procedure includes so-called "security questions" (which are secure from generic hacking, but pretty easy to defeat if you're being targeted) because I type gibberish into these. It's pretty irritating, but the worst I've ever had to do is re-calculate the taxes that I'd saved but not submitted.
Using the safe method works well enough, though. It's not as convenient, but any password that I use with any regularity gets ingrained in my muscle-memory quickly enough.
Thanks for the interesting discussion!
Note: most of the below is speculation intermixed with facts.
When Windows was originally created, there wasn't much thought given to security in this case--and probably with good reason. Back then, the issues for home PCs were largely viruses and trojans, not the self-spreading worms that we see today. The massive interconnectedness of today's computers probably wasn't expected, and viruses/trojans passed on floppy disk don't need a buffer overflow to spread.
So time passes, and Microsoft chooses to maintain as much backwards compatibility as possible between revisions of Windows...the Internet starts creeping up...Windows uses lots and lots of insecure, legacy code in newer versions, and all of a sudden, broadband starts becoming the norm, and every Windows computer on the Internet becomes a new vector of infection. All those controls which used to be in non-connected programs get tossed into Internet Explorer, and blammo--security hell. A few revisions later, and you get Windows XP SP2, which contained some measure of protection, and then Vista, in which much of the underlying support code got rewritten. We'll see whether it's actually all that it's cracked up to be, I guess.
By opening the document, the employee activated hidden software commands establishing what Reid described as backdoor communications with the hackers.
I take "hidden commands" to mean shellcode. The other possibility, a macro that auto-runs, wouldn't really require a patch to disable--it would only require changing a preference. Also, I think auto-running macros have been disabled by default for years, but I don't have anything to back that statement up.
So now we look at the payload--establishing backdoor communications with the hackers. How is this difficult? Trojans have been capable of doing this for years. It doesn't take much to start a daemon that queries a control server, listen for commands, and execute them.
The only thing left is the actual buffer overflow. If you're actually suggesting that Emacs is incapable of having a buffer overflow, that's an assertion I'd like to see a basis for, and is largely irrelevant since it was just an example. If you're asserting that OSS cannot have buffer overflows, then you're truly delusional. I was refuting the statement, "The fact that a simple Word document can cause such a big problem is really sad." Any exploitable buffer overflow is going to rely, in some way, on malicious user input. Any program which reads user input should be wary of the buffer overflow. This includes text editors. Or they embedded a regex or other code to look for the exact overflow and drop it instead of eliminating the overflow. Not that they've done anything like that before, right? Your attitude seems a bit hostile. I'm not trying to make any statement about the validity or correctness of their patch. That there was a patch implies that there was, indeed, something to patch. I used that plus other statements from the article to conclude that it was probably one of two vulnerabilities.
I don't know if you're a Linux zealot, a Microsoft hater, or both, but there's room for civility in discussions like this. I'm typing this from my personal notebook which only runs Linux. I don't use Windows for anything more than I am required by my job. That said, I recognize that security isn't just about what OS you run. I love Linux, but I also recognize the fact that there have been vulnerabilities in FOSS, and you can never forget the human factor (a trojan'd binary/script in Linux could do as much damage as one on Windows).
My mention of Outlook was because there's some functionality in Windows to send mail using the settings you've set up in Outlook, including username/password, proxy, port, server, etc. This means that a spambot can still send spam, even if port 25 is ACL'd off or the remote SMTP server requires authentication (assuming the user saved their password). Yeah, it's a Windows thing in this case, but mere exploitation of the system is not.
And just because anyone can look at the code doesn't mean that anyone does. While it is possible to get source for MS Windows programs, compiling it can be a nightmare although this depends on the skills of the person and the compiler used. In the majority of cases many people just download a "setup.exe' and run it. Of course this means that you completely trust the site and the download without any possibility of seeing the source code. But people do this with Linux and OSS all the time. They feel safer knowing that the code could be audited, but in reality, how often does anyone audit the code?
The buffer overflow would presuambly allow the trojan to execute any commands that the user could execute. If the user was running as Administrator (not stated in the article) then yes, it would gain control of the machine. If not, the trojan could read any file that the user could read, connect to any site that the user could connect to, send mail through the DLLs that Outlook uses, etc.
The article was short on details. The only thing in it that even hints at escalated privileges was the "tunnelling through the firewall" doubletalk, which, in my mind, means that it detected a proxy and used it.
That's all a trojan needs in order to steal data. Oh yes, it'd be handy to be able to hide and cover your tracks, and that almost certainly will require high privileges, but it's not necessary in order to do nasty things. A Linux trojan could still create a spambot that took orders from IRC or the web. It could even hide (to some degree) from the user it is running as (do you type
In the specific case of the State Dept, the intrusion was discovered very quickly. I read the article and don't recall them specifying that the privileges were escalated, and they also didn't mention whether or not the user was running as Administrator. Your assumptions aside, a malformed text file opened in emacs could have done the same damage as was mentioned in the article.
That's one of my favorite stories :)
Sourceforge has been compromised at least once in recent memory, and you're still trusting that the project maintainer isn't doing something nasty.
./configure and make because we trust them. Actually, the latter example would be easier to exploit, as it is explicitly running commands (whereas a Word document isn't expected to do so). The State department should not be opening documents from untrusted resources without performing some sort of verification on them, first. I don't care whether that verification is running them through antiword, opening them on computers in a DMZ, or what. Anything coming from the outside should be considered tainted until closely examined.
Anyway, the crux of the issue is that we make choices based upon convenience. We open Word documents from unknown senders because we are expecting invoices. We run
Runing ./configure or make or make install could cause just as large a problem. Do you read through those scripts before running them?
Furthermore, buffer overflows could exist in just about any program. There could be one in emacs right now, triggered by reading a file into the buffer. Then it would be "scary.. The fact that a simple text file can cause such a big problem is really sad."
Unfortunately, they didn't disclose the nature of the vulnerability. "hidden software commands" in the mass media could be anything from shellcode to an executable embedded in the document, to a macro. Since Microsoft patched it, it was probably either something that autoran or an overflow.