Israel National News, or Arutz Sheva (Channel 7) as it's more commonly known, is a heavily right wing biased media outlet whose management was recently sentenced to various prison terms for operating an illegal radio station.
But when the math is done and the image is presented the two low-res chroma channels are, in effect, low res datastreams responsible for the generation of red and blue video.
That's simply wrong. No amount of wiggling on your part changes the fact that the chroma encodes green.
Introductory material shouldn't be inaccurate. In fact, it mustn't be inaccurate, because that would make it incomprehensible to anyone who may have heard something about the subject matter before (for example, if anyone who heard that the luma component encodes a black and white image read your site, they'd wonder what happened to the green information).
Ok, I went and read the page about video formats. The bit about s-video is either completely wrong, or just confusing. From reading it, I get the feeling you're not clear on how RGB gets transformed into YCrCb, YUV, or whatever orthonormal basis those wacky video engineers dreamed up, so you introduce the idea of a red+blue signals (where did you get that, anyway?).
The chroma signal contains all the color information from the red, green and blue components. There is no green image at a higher resolution.
The gamer perspective is irrelevant. Video is video.
The page that demonstrates the effects of a noisy blue channel contains an error: DVD doesn't encode video in RGB. MPEG uses a YUV color space, in which there's a luma component, encoding the light intensity, and two chroma components, encoding the color. Typically, the chroma channels are encoded at half the resolution of the luminance. While working with MPEG encoders and decoders I got to "experiment" with the luma channel (read: I had horrible bugs that kept it either at its minimum or maximum intensity), and the chroma channels look very blurry, and hardly recognizable when displayed on their own. They obviously carry a lot less information than you'd guess.
If you're using any recent RedHat distribution, you can download apt-get for it from freshrpms.net. You could also try yum, which I found quite usable.
most other callback messages can only start executing at a point predefined by that process.
You said it yourself - most. The guy who found the WM_TIMER exploit claims there's more along those lines that he was able to exploit. I remember that there were other similar messages, but I don't remember the specifics. It's been years since I've done anything serious with Win32.
Why can't Win32 be sandboxed? They put DOS apps into NTVDM, Win16 apps run in wowexec, why not run Win32 in a layer of its own? Mac did it with classic.
Of course they can, but that would amount to rewriting the OS (the OS is more than just the kernel), because much of the OS talks to Win32, and that would have to change. Your example illustrates this - Apple sandboxed classic, but it paid the price - they did rewrite the OS.
Also, I'm not sure that "sandboxing" Win16 and DOS was the proper term. They provided the ABI required by those apps, but didn't do much in the way of securing them, and trapping attempts to compromise the system. This wasn't a sandbox in the sense that the JVM is a sandbox, for example.
But the point is that whatever problems there are presently in windows, the solution does not require rewriting everything from scratch.
Literally, you're right - nothing ever requires reqriting "everything" from scratch. You can always reuse bits and pieces, at the very least. But the fact is that you're describing Microsoft's effort to rearchitect Windows in a way that amounts to a rewrite, in the sense that it'll take years, a lot of effort, and a great risk.
The WM_Timer exploit was patched a long time ago. This is no longer an issue.
The paper I linked to has a followup where the author claims the WM_TIMER was only one facet of a deeper problem. He claims to have found numerous other exploitable problems that weren't fixed by Microsoft.
In any case Windows Messages are only part of Win32 and not part of the NT kernel.
Arguing that the NT kernel is meaningless, unless you can show me how to install a usable NT kernel without Win32 support. Also, the fact that Microsoft is finally shipping a safer API won't change anything if they won't stop shipping Win32, which they won't for a very long time.
In any case, the architecture you're describing is obsolete - Since NT 4.0, Microsoft has been pulling Win32 components into the kernel.
I don't see how Win32 can be "increasingly sandboxed" in the way you're describing. Unless you're suggesting that WinFX is going to be sitting directly on top of the NT kernel in Longhorn, and Win32 is going to be an optional subsystem, I don't see how this problem is going to be solved any time soon.
I certaintly don't agree that it requires a rewrite of the OS to fix.
Theoretically, a change to the Win32 API at that level would require sweeping changes to every part of the OS, and to every Windows application ever written. Microsoft can certainly start patching the API when people find problems, but they can't realistically make any changes that are not backwards compatible. Would such a change amount to rewriting the OS? No, not literally, but in terms of the work involved it might get close.
Have you read the followup? The author claims to have exploited similar weaknesses in MS software. You're right that Norton shouldn't have architected their application the way they did, but other people make the same mistake, Microsoft included.
As for the issue of memory protection between processes, what are you refering to?
I was refering to the old 16 bit Windows API, which the Win32 API is based on. My original post was phrased rather poorly - sorry.
Win32's roots in the 16 bit Windows API are the reason why the class of problems described in the paper I mentioned exist - applications used to be able to pass pointers around like cookies (Microsoft's words - not mine), and that includes pointers to timer callbacks. You can still get an application to map your data (potentially, exploit code) into its virtual memory space by sending it a WM_COPYDATA message. This was done, I assume, to make it easier to port applications that relied on the lack of memory protection to the new Win32 API.
While I agree that the author is poorly informed and mostly goes on one tangent after the other in this article, there are some problems with Windows that aren't easily fixed. This page, mentioned previously on/., is one example:
There is a followup to this paper that discusses Microsoft response the it. The author isn't happy with the response.
The root of this issue is the Win32 API, and its origins as a real mode compatible API with no security, and no memory protection between processes. Much of the transition to Win32 seems to have been handled as a massive search and replace operation on the Windows headers, with backwards compatibility being considered more important than security.
Maybe. In a large project, it becomes difficult to find the right place to fix the bug
So? It's still easier than reading tons of source and out of date documentation (documentation is always out of date).
When I had to work with the Mozilla source code, I found that the most effective way to do it was to go right in and implement a feature. Some of the interfaces I had to use were documented, and some weren't. Where no documentation was available, I had to read the surrounding code, a few layers of calls, typically, to understand what was going on. I didn't really understand how things worked until I tried a few things, and saw how they didn't work.
Mozilla is a big project, it comes with its own middleware, and at least when I worked with it, it was poorly documented. Probing it was the only effective way I found to understand how parts of it worked.
Not to mention that a rather vast amount of bugs don't do something "visible"
Bugs always do something "visible", or they wouldn't be bugs. By "visible" I mean visible to the end user - it can be a protocol stack that sends the wrong message, an MPEG encoder that flips a bit in a picture header, or a real-time scheduler that's late to schedule a process - these bugs are all visible to the person who's bitten by them.
If you don't have a good understanding of the overall architecture your "fix" can easily break other concepts or code outright.
Of course. That's why you don't typically get cvs write permissions right away, and if you screw up, you typically get an explanation of exactly how you screwed up, but it's done in a context with which you're already familiar (you already worked with the code in question), so your chances of understanding the explanation are greater than if you just read the code and didn't try to work with it.
I've tried to read large bodies of code before. It's damn hard, even if it is documented. And when it isn't documented, your beginning developers don't have a chance.
They have a chance if they start by fixing a bug. It gives focus to the effort of reading the code, and imposes a structure on how you must do it. It's also a great motivator.
Instead of reading random files, and trying to make sense of things this way, you start with a symptom (Widget caption isn't updating to reflect a state change, for example), go straight to where the code deals with the part you're interested in (grep "Wrong caption" *.c) and get an immediate feel for how things work in the close neighborhood of the bug (Hmmm... There's a function here that looks like it should do this, but it doesn't. Who calls it? Under what circumstances? grep some more...)
And at the end, you've done something visible, that didn't take as much work as reading half the source files in the project, and you've earned some credibility with the project maintainers.
there is no such thing as a totally secure box that is connected to a network
Of course there isn't. The difference is that Microsoft just realized this, and it's going to take them a few more years to lock down their system, while Unix has been fighting this battle for over 20 years now. Both systems weren't really designed with security in mind, but if you're trying to run a secure server today, you're better off running Unix.
But the problem is, is that it is a waist of time to make a exploit for only 10% of the market
It's only a waste of time if an attacker has nothing to gain from the attack. There are still perfectly good reasons to target Linux machines - stealing credit card numbers, sending spam or proving a point.
Also, people seem to forget that the original Mac OS had plenty of viruses, despite having roughly the same market share as OS X. It also had an inherently insecure design (about on par with DOS).
but if the tables were reversed and Linux had 90% of the market, there would be just as many Linux exploits and worms as their are for Microsoft now.
That's speculation, and isn't supported by facts. You're too quick to dismiss the Apache counter example, where a product that's more widely used is exploited less than a minority product. That's why I brought up Apache.
Yeah that is also fine to say the Linux Kernel is becomming more secure but that statement really doesn't gauge where the Linux Kernel is compared to Windows. It just says that the Linux Kernel is progressing.
It says more than that, actually. If Windows had similar functionality in its kernel, it would have made it a lot more difficult to exploit Windows security hole. It would have been harder for a worm to infect a large portion of the internet in less than an hour. This just shows one area of system security where Linux can have a clear advantage at this point.
In any case, I was replying to this:
"It is about time we recongnized this, and start making changes in the Kernel to secure the OS"
Of course, exec-shield wouldn't have helped against the PHP exploit described here a few days ago. Running those PHP scripts on any platform would have made you vulnerable, because they made it possible for an attacker to run arbitrary code on the server.
There are more IIS worms than Apache worms, despite Apache being the market leader. By the logic of your quote, Apache should have been the more widely exploited web server, not IIS.
And the Linux kernel is becoming more secure. Even as we speak, you can download and install Fedora Core 1, which comes with exec-shield enabled by default. It makes the common buffer overflow security holes much harder to exploit without being detected.
Sam: Let's go sailing! Otto: Technically, we can't go sailing, because I don't have a sail. You can say "let's go floating" or something like that. Sam: Oh, OK. Let's go sailing! Otto: OK!
Slashdot Mirror
Israel National News, or Arutz Sheva (Channel 7) as it's more commonly known, is a heavily right wing biased media outlet whose management was recently sentenced to various prison terms for operating an illegal radio station.
More details here
It's an odd source for tech news.
That's simply wrong. No amount of wiggling on your part changes the fact that the chroma encodes green.
Introductory material shouldn't be inaccurate. In fact, it mustn't be inaccurate, because that would make it incomprehensible to anyone who may have heard something about the subject matter before (for example, if anyone who heard that the luma component encodes a black and white image read your site, they'd wonder what happened to the green information).
Ok, I went and read the page about video formats. The bit about s-video is either completely wrong, or just confusing. From reading it, I get the feeling you're not clear on how RGB gets transformed into YCrCb, YUV, or whatever orthonormal basis those wacky video engineers dreamed up, so you introduce the idea of a red+blue signals (where did you get that, anyway?).
The chroma signal contains all the color information from the red, green and blue components. There is no green image at a higher resolution.
The gamer perspective is irrelevant. Video is video.
My DVD certainly doesn't work like that.
The page that demonstrates the effects of a noisy blue channel contains an error: DVD doesn't encode video in RGB. MPEG uses a YUV color space, in which there's a luma component, encoding the light intensity, and two chroma components, encoding the color. Typically, the chroma channels are encoded at half the resolution of the luminance. While working with MPEG encoders and decoders I got to "experiment" with the luma channel (read: I had horrible bugs that kept it either at its minimum or maximum intensity), and the chroma channels look very blurry, and hardly recognizable when displayed on their own. They obviously carry a lot less information than you'd guess.
Surely not all of them. I thought the cube was great.
Merry Christmas from your friendly neighborhood Jew!
I miss apt-get
If you're using any recent RedHat distribution, you can download apt-get for it from freshrpms.net. You could also try yum, which I found quite usable.
Unless it's as 'root@eruditorum.org'. Then it's a sure sign you're a poser.
You said it yourself - most. The guy who found the WM_TIMER exploit claims there's more along those lines that he was able to exploit. I remember that there were other similar messages, but I don't remember the specifics. It's been years since I've done anything serious with Win32.
Of course they can, but that would amount to rewriting the OS (the OS is more than just the kernel), because much of the OS talks to Win32, and that would have to change. Your example illustrates this - Apple sandboxed classic, but it paid the price - they did rewrite the OS.
Also, I'm not sure that "sandboxing" Win16 and DOS was the proper term. They provided the ABI required by those apps, but didn't do much in the way of securing them, and trapping attempts to compromise the system. This wasn't a sandbox in the sense that the JVM is a sandbox, for example.
Literally, you're right - nothing ever requires reqriting "everything" from scratch. You can always reuse bits and pieces, at the very least. But the fact is that you're describing Microsoft's effort to rearchitect Windows in a way that amounts to a rewrite, in the sense that it'll take years, a lot of effort, and a great risk.
The paper I linked to has a followup where the author claims the WM_TIMER was only one facet of a deeper problem. He claims to have found numerous other exploitable problems that weren't fixed by Microsoft.
Arguing that the NT kernel is meaningless, unless you can show me how to install a usable NT kernel without Win32 support. Also, the fact that Microsoft is finally shipping a safer API won't change anything if they won't stop shipping Win32, which they won't for a very long time.
In any case, the architecture you're describing is obsolete - Since NT 4.0, Microsoft has been pulling Win32 components into the kernel.
I don't see how Win32 can be "increasingly sandboxed" in the way you're describing. Unless you're suggesting that WinFX is going to be sitting directly on top of the NT kernel in Longhorn, and Win32 is going to be an optional subsystem, I don't see how this problem is going to be solved any time soon.
Theoretically, a change to the Win32 API at that level would require sweeping changes to every part of the OS, and to every Windows application ever written. Microsoft can certainly start patching the API when people find problems, but they can't realistically make any changes that are not backwards compatible. Would such a change amount to rewriting the OS? No, not literally, but in terms of the work involved it might get close.
This is all moot, because it'll never happen.
I was refering to the old 16 bit Windows API, which the Win32 API is based on. My original post was phrased rather poorly - sorry.
Win32's roots in the 16 bit Windows API are the reason why the class of problems described in the paper I mentioned exist - applications used to be able to pass pointers around like cookies (Microsoft's words - not mine), and that includes pointers to timer callbacks. You can still get an application to map your data (potentially, exploit code) into its virtual memory space by sending it a WM_COPYDATA message. This was done, I assume, to make it easier to port applications that relied on the lack of memory protection to the new Win32 API.
While I agree that the author is poorly informed and mostly goes on one tangent after the other in this article, there are some problems with Windows that aren't easily fixed. This page, mentioned previously on /., is one example:
http://security.tombom.co.uk/shatter.html
There is a followup to this paper that discusses Microsoft response the it. The author isn't happy with the response.
The root of this issue is the Win32 API, and its origins as a real mode compatible API with no security, and no memory protection between processes. Much of the transition to Win32 seems to have been handled as a massive search and replace operation on the Windows headers, with backwards compatibility being considered more important than security.
The notable exception are security bugs, which often don't affect the way the system works when given its expected input.
So? It's still easier than reading tons of source and out of date documentation (documentation is always out of date).
When I had to work with the Mozilla source code, I found that the most effective way to do it was to go right in and implement a feature. Some of the interfaces I had to use were documented, and some weren't. Where no documentation was available, I had to read the surrounding code, a few layers of calls, typically, to understand what was going on. I didn't really understand how things worked until I tried a few things, and saw how they didn't work.
Mozilla is a big project, it comes with its own middleware, and at least when I worked with it, it was poorly documented. Probing it was the only effective way I found to understand how parts of it worked.
Bugs always do something "visible", or they wouldn't be bugs. By "visible" I mean visible to the end user - it can be a protocol stack that sends the wrong message, an MPEG encoder that flips a bit in a picture header, or a real-time scheduler that's late to schedule a process - these bugs are all visible to the person who's bitten by them.
Of course. That's why you don't typically get cvs write permissions right away, and if you screw up, you typically get an explanation of exactly how you screwed up, but it's done in a context with which you're already familiar (you already worked with the code in question), so your chances of understanding the explanation are greater than if you just read the code and didn't try to work with it.
They have a chance if they start by fixing a bug. It gives focus to the effort of reading the code, and imposes a structure on how you must do it. It's also a great motivator.
Instead of reading random files, and trying to make sense of things this way, you start with a symptom (Widget caption isn't updating to reflect a state change, for example), go straight to where the code deals with the part you're interested in (grep "Wrong caption" *.c) and get an immediate feel for how things work in the close neighborhood of the bug (Hmmm... There's a function here that looks like it should do this, but it doesn't. Who calls it? Under what circumstances? grep some more...)
And at the end, you've done something visible, that didn't take as much work as reading half the source files in the project, and you've earned some credibility with the project maintainers.
Irrelevant. exec-shield helps prevent application security holes from being exploited. Read up on it.
there is no such thing as a totally secure box that is connected to a network
Of course there isn't. The difference is that Microsoft just realized this, and it's going to take them a few more years to lock down their system, while Unix has been fighting this battle for over 20 years now. Both systems weren't really designed with security in mind, but if you're trying to run a secure server today, you're better off running Unix.
But the problem is, is that it is a waist of time to make a exploit for only 10% of the market
It's only a waste of time if an attacker has nothing to gain from the attack. There are still perfectly good reasons to target Linux machines - stealing credit card numbers, sending spam or proving a point.
Also, people seem to forget that the original Mac OS had plenty of viruses, despite having roughly the same market share as OS X. It also had an inherently insecure design (about on par with DOS).
So for that community Amiga had 100% of the market, so proving the theory correct of the author.
And for the MacOS community the Mac has 100% of the market, thus disproving it.
Go get a cup of coffee or something - you're not thinking clearly.
but if the tables were reversed and Linux had 90% of the market, there would be just as many Linux exploits and worms as their are for Microsoft now.
That's speculation, and isn't supported by facts. You're too quick to dismiss the Apache counter example, where a product that's more widely used is exploited less than a minority product. That's why I brought up Apache.
Yeah that is also fine to say the Linux Kernel is becomming more secure but that statement really doesn't gauge where the Linux Kernel is compared to Windows. It just says that the Linux Kernel is progressing.
It says more than that, actually. If Windows had similar functionality in its kernel, it would have made it a lot more difficult to exploit Windows security hole. It would have been harder for a worm to infect a large portion of the internet in less than an hour. This just shows one area of system security where Linux can have a clear advantage at this point.
In any case, I was replying to this:
"It is about time we recongnized this, and start making changes in the Kernel to secure the OS"
Of course, exec-shield wouldn't have helped against the PHP exploit described here a few days ago. Running those PHP scripts on any platform would have made you vulnerable, because they made it possible for an attacker to run arbitrary code on the server.
There are more IIS worms than Apache worms, despite Apache being the market leader. By the logic of your quote, Apache should have been the more widely exploited web server, not IIS.
And the Linux kernel is becoming more secure. Even as we speak, you can download and install Fedora Core 1, which comes with exec-shield enabled by default. It makes the common buffer overflow security holes much harder to exploit without being detected.
Jennie is NOT a cam girl!!!
Sam: Let's go sailing!
Otto: Technically, we can't go sailing, because I don't have a sail. You can say "let's go floating" or something like that.
Sam: Oh, OK. Let's go sailing!
Otto: OK!
I think they just really really wanted that display. The Slimp3 and the squeezebox are geek toys more than they are consumer products, and it shows.
As long as the server can run text-mode
It does. The server is a perl script running from the console.