The backdoor was ultimately found by outside researchers/explorers/whoever through the process you mention. HOWEVER, my comment speaks more to how such backdoors can persist for years and years, hidden from the developers themselves, until someone's motivated enough to pop the code up into a debugger and start pulling it apart.
In a sense, this provides a strange twist in the open-vs-closed source. It doesn't really argue strongly for either, but rather shows that on this particular aspect, they're each different. With open source, because the source is available, most people looking for holes won't look past the source for vulnerabilities. With closed source, all you have is the binary object file, and so that's what people will pull apart. Ultimately, the only way to truly be sure there are no back doors is to do the latter, but that's more likely to happen with closed source software than open source.
The flipside of the above observation is that when a bug is found, open source patches are usually (but not always) quicker to arrive on the scene. At the very least, people have a chance of patching locally.
One scary aspect of the observations in Reflections is that even Linux could be vulnerable to such an attack. Imagine if someone manages to sneak a hack such as Ken Thompson described into some GCC "binary bootstrap" packages used by a "compile it yourself" distro such as Gentoo? Here you are, feeling all high and mighty, compiling all the packages on your system from source (including GCC even), but given the chicken-and-egg nature of compilers and binaries, you're using a hacked GCC binary and don't know it. Oops.
But anyway, to the substance of your post: The post I replied to was asking for lists of other backdoors. I think Ken's was rather relevant.
I'm surprised nobody's trotted out Reflections on Trusting Trust, by Ken Thompson. Not only does this discuss a backdoor, but also a backdoor that can't be found by examining the source code.
...unless part of your exploit involves somehow setting up the SIGFPE (div-by-zero) or SIGSEGV (NULL-ptr-dereference) handler to run your code. But, then, that'd take exploiting TWO bugs.
Unlikely. I doubt Linux will invoke callback hooks in WMFs that are intended to call into Windows code, and so the primary vulerability just isn't going to be there on a platform other than Windows. Sure, it was an ability designed-into WMF, but it was only meant to be used for WMFs passed around within and between live apps, not for WMFs stored on disk. There's no rational reason for libwmf to even care about that particular part of the WMF file.
The other two flaws seem to be implementation specific coding errors.
Ah yes, The Pinball Song, featuring the Pointer Sisters! (Link goes to a remix version with a remixed video as well.) If that link doesn't work, I've put a copy on my DSL. Don't hit me too hard, or I'll remove it.
Oh, and it didn't come from Sesame Street, apparently. It came from The Electric Company.
Back when I was still in college, I'd walk around the EE lab and hum a bar or two under my breath as I walked by someone. The target would often then start humming the tune and have it stuck in their head the rest of the day. Mission accomplished.:-)
Of course, educators can be stupid even without software. Back when my brother and I were in elementary school, they had this incentive thing going where if you read a certain number of books of a certain minimum length (125 pages, as I recall), you'd get a free personal pan pizza over at Pizza Hut.
At the time, I was devouring Encyclopedia Brown books. All of those books, though, weighed in at 100-115 pages. None of them counted. So, for me, it was a net demotivator. I wasn't going to put aside the books I *wanted* to read (and had read easily over a 1000 pages worth of), to read books I had no real interest in. Besides, in retrospect, the Encyclopedia Brown books were good for stimulating lateral thinking. Judging by how I approach problems at work, I think it did me some good.
In contrast, my brother discovered a way to cheat the system. He was younger than me, and so I had already progressed past the grades that offered this incentive program. He discovered that Twist-A-Plot and related books *did* qualify. Most were just over the page cutoff length, and you only had to read as far as getting the protagonist killed. He got a lot of pizzas with that shortcut.
Erf... I dropped a phrase from one sentence. Here's a minor edit: "...and you use the same pseudo-random number for a given pixel position across all images in a sequence..."
Actually, some programs implement various forms of stochastic dithering (random rounding) for that reason. What those algorithms do is add a random or pseudo-random number to each value to cause fractional values to quantize either to the next larger or next smaller number with a probability related to the fractional value.
How does that help? The end result is slightly noisier than the Floyd-Steinberg case, but you stand the opportunity to make things look better in mouse-overs and animations. Specifically, if you use pseudo-random numbers for the random component, and you use the same pseudo-random number for a given pixel position, then you have "stable noise," avoiding the inherent sparkling that you'd otherwise get over the course of an image due to algorithms like Floyd Steinberg. You also avoid the cross-hatch pattern that fixed dither patterns like "ordered dither" give you.
Ordered dither and stochastic dither are actually nearly equivalent for the most part. Both add a "rounding pattern" to the image before quantizing, with ordered dither adding a fixed pattern and stochastic dither adding a random or pseudo-random pattern. This PDF file seems to give a good, brief overview of various quantization techniques for images.
You probably hate Floyd-Steinberg for web development--it screws up mouse-overs and bloats GIFs--but what you probably don't realize is that all those "1-bit DAC" CD players with "BIGNUMx oversampling" out there are using delta-sigma modulation, which is the same concept of error-diffusion, but for a 1 dimensional signal.
Is it that hard to add/subtract 3 months and a handful of days? Ignoring that the standardized gestational period is about 266 days, it seems like 3 months "give or take a week" should be easy for just about anyone. (Hint: If given the due date, add 3 months and 9 days to get approx. date of conception on the previous year. If given the conception date, subtract 3 months and 9 days to get approx. date of birth on the following year.) This isn't multiplication or exponentiation. (Ok, it's a different sort of multiplication... but that's a different story.)
Chances are, in a situation like this, "give or take a month" is all the precision you need.
That's the basis behind delta-sigma modulation and Floyd-Steinberg dithering. You carry forward the cumulative error from previous quantization, adding it to the current term. Then you quantize as desired. Over multiple samples, the error gets spread out, such that the local average is very close to the original signal.
Armed Robber: No nonsense. Just give me all your money.
Mr Logic: I shall commence by pointing out to you that my demeanour is
not one which could be described as nonsensical. Consequently I can
attest you have no cause to reprimand me on . . .
*BANG*
Mr Logic: Might I point out that in shooting yourself in that manner,
in no condition to receive my money. You will no doubt be
unsurprised when . . .
*BANG*
Customer: Good thing Mr Logic is so full of himself he didn't see me
pick up the gun. I hope the surveillance tapes record audio, so
I can prove it was in self defense... of my SANITY!
I've so far managed to get mplayer to build as a 32-bit app under Ubuntu 5.04 on my AMD64 box. I haven't managed to get sound to work though.
It'd be cool if Linux managed to build a 64-to-32 thunking layer that let 64-bit apps dynamically load 32-bit libraries. That'd open up 32-bit plugins and codecs to native 64-bit apps.
BTW, there is some benefit to true dual core over independent FSB hookups. Mainly, core-to-core latency can be much lower and core-to-core bandwidth can be much higher.
Whereas I've used the parallel port on my last two laptops to talk to various things, including my EPROM burner, some custom hardware I built, a JTAG interface, an Intellivision joystick interface, and (believe it or not) an actual printer! I just got a new laptop that also has a parallel port so I can continue to do those things.
I think his point is that you can mislead a programmer pretty easily because they'll read the English before they read the C, and when they read the C, the C itself can be misleading. Witness the IOCCC. A programmer who knows their code will be visible to the world may take extreme steps to obfuscate and mislead, at least in the portion of the code that contains sensitive information and/or algorithms.
If you read the binary, you see exactly what the machine executes and no more. A lazy programmer that's shipping only a binary might figure compilation alone is sufficient to obscure the key and the algorithm and thus won't take steps to further obscure the key or its corresponding algorithm. Thus, the object code will likely be very direct and easier to reverse.
For an extreme case where browsing the source doesn't help you one bit, read Reflections on Trusting Trust, by none other than Ken Thompson.
The experiment was flawed. The existing site had a long established click-through rate and so was ranked highly on its click-through virtue. The mirror site did not have such a long history.
This experiment would be more valid if the two sites had existed for the same amount of time.
Could it be that hard-disk write-caching is enabled on the dying computer, and disabled (or less aggressive) on the others? Check your IDE driver's settings and disable write caching if it's enabled.
Oh, and like eleventy-billion other people said: Get a UPS.
Oh, I realize the SoC architecture of DaVinci does evoke some of the same distributed compute concepts as Amiga's "three sisters." I was attempting to make a lame joke, as Commodore refused to kill the C64 and push the Amiga (here in the states, at least) and in the end the whole company became irrelevant...
Yeah, that does suck that DAT_copy got broken. I worked with the guys that defined it initially. I do remember there was an integer-wrapping problem that broke it for a little while years ago (C6211 days), but I didn't think that escaped the lab.
The ownership of that code's shifted around a few times. That's more reflective of our internal organizational structure than anything else. The DSP software applications teams have changed shape a couple times since I was last a member of that group. These days I'm on an architecture team, so I'm kinda out of touch with how they're shaped specifically today.
I'd love it if we put more people on our tools teams. I know I raise that point whenever I can here at work. TI is a silicon company first, though, so that's where they tend to put their money first. Like I said, I've seen some internal organizational shifts that I hope also signal a change in attitude towards tools investment. That's about all I can say, though.
I'm not trying to be an apologist. When I speak here, it's for me, not the company. I can say generically, though, that internal customers can sometimes be as frustrated as external customers.:-)
Slashdot Mirror
The backdoor was ultimately found by outside researchers/explorers/whoever through the process you mention. HOWEVER, my comment speaks more to how such backdoors can persist for years and years, hidden from the developers themselves, until someone's motivated enough to pop the code up into a debugger and start pulling it apart.
In a sense, this provides a strange twist in the open-vs-closed source. It doesn't really argue strongly for either, but rather shows that on this particular aspect, they're each different. With open source, because the source is available, most people looking for holes won't look past the source for vulnerabilities. With closed source, all you have is the binary object file, and so that's what people will pull apart. Ultimately, the only way to truly be sure there are no back doors is to do the latter, but that's more likely to happen with closed source software than open source.
The flipside of the above observation is that when a bug is found, open source patches are usually (but not always) quicker to arrive on the scene. At the very least, people have a chance of patching locally.
One scary aspect of the observations in Reflections is that even Linux could be vulnerable to such an attack. Imagine if someone manages to sneak a hack such as Ken Thompson described into some GCC "binary bootstrap" packages used by a "compile it yourself" distro such as Gentoo? Here you are, feeling all high and mighty, compiling all the packages on your system from source (including GCC even), but given the chicken-and-egg nature of compilers and binaries, you're using a hacked GCC binary and don't know it. Oops.
But anyway, to the substance of your post: The post I replied to was asking for lists of other backdoors. I think Ken's was rather relevant.
--Joe
I'm surprised nobody's trotted out Reflections on Trusting Trust, by Ken Thompson. Not only does this discuss a backdoor, but also a backdoor that can't be found by examining the source code.
Nice leap of logic there. Kinda like saying: All dogs have eyes. I have eyes. Therefore I'm a dog.
...unless part of your exploit involves somehow setting up the SIGFPE (div-by-zero) or SIGSEGV (NULL-ptr-dereference) handler to run your code. But, then, that'd take exploiting TWO bugs.
Unlikely. I doubt Linux will invoke callback hooks in WMFs that are intended to call into Windows code, and so the primary vulerability just isn't going to be there on a platform other than Windows. Sure, it was an ability designed-into WMF, but it was only meant to be used for WMFs passed around within and between live apps, not for WMFs stored on disk. There's no rational reason for libwmf to even care about that particular part of the WMF file.
The other two flaws seem to be implementation specific coding errors.
Ah yes, The Pinball Song, featuring the Pointer Sisters! (Link goes to a remix version with a remixed video as well.) If that link doesn't work, I've put a copy on my DSL. Don't hit me too hard, or I'll remove it.
:-)
Oh, and it didn't come from Sesame Street, apparently. It came from The Electric Company.
Back when I was still in college, I'd walk around the EE lab and hum a bar or two under my breath as I walked by someone. The target would often then start humming the tune and have it stuck in their head the rest of the day. Mission accomplished.
--Joe
Of course, educators can be stupid even without software. Back when my brother and I were in elementary school, they had this incentive thing going where if you read a certain number of books of a certain minimum length (125 pages, as I recall), you'd get a free personal pan pizza over at Pizza Hut.
At the time, I was devouring Encyclopedia Brown books. All of those books, though, weighed in at 100-115 pages. None of them counted. So, for me, it was a net demotivator. I wasn't going to put aside the books I *wanted* to read (and had read easily over a 1000 pages worth of), to read books I had no real interest in. Besides, in retrospect, the Encyclopedia Brown books were good for stimulating lateral thinking. Judging by how I approach problems at work, I think it did me some good.
In contrast, my brother discovered a way to cheat the system. He was younger than me, and so I had already progressed past the grades that offered this incentive program. He discovered that Twist-A-Plot and related books *did* qualify. Most were just over the page cutoff length, and you only had to read as far as getting the protagonist killed. He got a lot of pizzas with that shortcut.
--Joe
Erf... I dropped a phrase from one sentence. Here's a minor edit: "...and you use the same pseudo-random number for a given pixel position across all images in a sequence..."
--Joe
Actually, some programs implement various forms of stochastic dithering (random rounding) for that reason. What those algorithms do is add a random or pseudo-random number to each value to cause fractional values to quantize either to the next larger or next smaller number with a probability related to the fractional value.
How does that help? The end result is slightly noisier than the Floyd-Steinberg case, but you stand the opportunity to make things look better in mouse-overs and animations. Specifically, if you use pseudo-random numbers for the random component, and you use the same pseudo-random number for a given pixel position, then you have "stable noise," avoiding the inherent sparkling that you'd otherwise get over the course of an image due to algorithms like Floyd Steinberg. You also avoid the cross-hatch pattern that fixed dither patterns like "ordered dither" give you.
Ordered dither and stochastic dither are actually nearly equivalent for the most part. Both add a "rounding pattern" to the image before quantizing, with ordered dither adding a fixed pattern and stochastic dither adding a random or pseudo-random pattern. This PDF file seems to give a good, brief overview of various quantization techniques for images.
You probably hate Floyd-Steinberg for web development--it screws up mouse-overs and bloats GIFs--but what you probably don't realize is that all those "1-bit DAC" CD players with "BIGNUMx oversampling" out there are using delta-sigma modulation, which is the same concept of error-diffusion, but for a 1 dimensional signal.
--Joe
Is it that hard to add/subtract 3 months and a handful of days? Ignoring that the standardized gestational period is about 266 days, it seems like 3 months "give or take a week" should be easy for just about anyone. (Hint: If given the due date, add 3 months and 9 days to get approx. date of conception on the previous year. If given the conception date, subtract 3 months and 9 days to get approx. date of birth on the following year.) This isn't multiplication or exponentiation. (Ok, it's a different sort of multiplication... but that's a different story.)
Chances are, in a situation like this, "give or take a month" is all the precision you need.
That's the basis behind delta-sigma modulation and Floyd-Steinberg dithering. You carry forward the cumulative error from previous quantization, adding it to the current term. Then you quantize as desired. Over multiple samples, the error gets spread out, such that the local average is very close to the original signal.
Are you sure the exchange wasn't more like:
Armed Robber: No nonsense. Just give me all your money.
Mr Logic: I shall commence by pointing out to you that my demeanour is not one which could be described as nonsensical. Consequently I can attest you have no cause to reprimand me on . . .
*BANG*
Mr Logic: Might I point out that in shooting yourself in that manner, in no condition to receive my money. You will no doubt be unsurprised when . . .
*BANG*
Customer: Good thing Mr Logic is so full of himself he didn't see me pick up the gun. I hope the surveillance tapes record audio, so I can prove it was in self defense... of my SANITY!
--Joe
I've so far managed to get mplayer to build as a 32-bit app under Ubuntu 5.04 on my AMD64 box. I haven't managed to get sound to work though.
It'd be cool if Linux managed to build a 64-to-32 thunking layer that let 64-bit apps dynamically load 32-bit libraries. That'd open up 32-bit plugins and codecs to native 64-bit apps.
Another good example is the Bell System. (Two links there.)
That's £2500, not 2500 or $2500. £2500 is around $4300 at current exchange rates.
BTW, there is some benefit to true dual core over independent FSB hookups. Mainly, core-to-core latency can be much lower and core-to-core bandwidth can be much higher.
Whereas I've used the parallel port on my last two laptops to talk to various things, including my EPROM burner, some custom hardware I built, a JTAG interface, an Intellivision joystick interface, and (believe it or not) an actual printer! I just got a new laptop that also has a parallel port so I can continue to do those things.
--Joe
The remaining question is: What exactly is in a can of whoop-ass?
I think his point is that you can mislead a programmer pretty easily because they'll read the English before they read the C, and when they read the C, the C itself can be misleading. Witness the IOCCC. A programmer who knows their code will be visible to the world may take extreme steps to obfuscate and mislead, at least in the portion of the code that contains sensitive information and/or algorithms.
If you read the binary, you see exactly what the machine executes and no more. A lazy programmer that's shipping only a binary might figure compilation alone is sufficient to obscure the key and the algorithm and thus won't take steps to further obscure the key or its corresponding algorithm. Thus, the object code will likely be very direct and easier to reverse.
For an extreme case where browsing the source doesn't help you one bit, read Reflections on Trusting Trust, by none other than Ken Thompson.
--Joe
The experiment was flawed. The existing site had a long established click-through rate and so was ranked highly on its click-through virtue. The mirror site did not have such a long history.
This experiment would be more valid if the two sites had existed for the same amount of time.
I think the class A the GP was refering to as Compaq's class A was the class A it inherited from DEC.
Could it be that hard-disk write-caching is enabled on the dying computer, and disabled (or less aggressive) on the others? Check your IDE driver's settings and disable write caching if it's enabled.
Oh, and like eleventy-billion other people said: Get a UPS.
--Joe
Oh, I realize the SoC architecture of DaVinci does evoke some of the same distributed compute concepts as Amiga's "three sisters." I was attempting to make a lame joke, as Commodore refused to kill the C64 and push the Amiga (here in the states, at least) and in the end the whole company became irrelevant...
Yeah, that does suck that DAT_copy got broken. I worked with the guys that defined it initially. I do remember there was an integer-wrapping problem that broke it for a little while years ago (C6211 days), but I didn't think that escaped the lab.
The ownership of that code's shifted around a few times. That's more reflective of our internal organizational structure than anything else. The DSP software applications teams have changed shape a couple times since I was last a member of that group. These days I'm on an architecture team, so I'm kinda out of touch with how they're shaped specifically today.
--Joe
I'd love it if we put more people on our tools teams. I know I raise that point whenever I can here at work. TI is a silicon company first, though, so that's where they tend to put their money first. Like I said, I've seen some internal organizational shifts that I hope also signal a change in attitude towards tools investment. That's about all I can say, though.
:-)
I'm not trying to be an apologist. When I speak here, it's for me, not the company. I can say generically, though, that internal customers can sometimes be as frustrated as external customers.