I've been working with JsOrb (which lets you call your Java interfaces from Javascript) and one of the nice things about it is that when used correctly it makes XSS vulnerabilities go away. Since the data is encoded inside XML messages, the browser takes care of properly escaping all those goofy characters into & for you.
Never did I think I'd actually be glad to be a Qwest customer. I mean, after all the rolling over that Qwest has done, all the anti-customer behavior, I'm surprised they took the moral high ground.
Oh, wait. They didn't, they were just afraid they'd get sued.
I remember having being burnt by a GC bug in 1.1.7 (can't remember exactly which version it was in 98 I think) where the GC would remove objects when they were only referred by a static handle (classic singleton pattern).
Holy cow I remember that bug! You needed to use the -noclassgc option to keep it from happening.
While I agree that when using a new system you'll find more bugs, it doesn't mean that you need to do any less testing on an older, more "established" system. That's the mistake made on several of the bugs in the article: they assumed that since the underlying components were used before, they must be stable.
It was a GUI/workflow app, not a hardware control system. Diagnostic Radiology is when a radiologist is looking at your images (think of the digital equivalent of a lightbox on the wall). Our system could bring up the patient's historical exams (useful for cancer patients), cross-reference exams in different orientations (coronal, saggital, and axial), make annotations, and dictate a diagnosis into an automated dictation system.
Radiation treatment is the kind of system where there's a gun to turn on/off. This is a system some friends of mine have built that is truly amazing. If you have a lung tumor near the spine, this thing takes into account your lungs' expansion while you breathe (in realtime) as it administers the dose. The math is, umm, a bit stunning.
It really doesn't matter what language you use: bugs can be written in any of them. In this case, the customer wanted a GUI workstation running on Windows, with the possibility of being cross-platform. Java was new and cool (1.1 had been out for six week when we started), and they decided to give it a shot. This is a company with fifty years experience in medical systems, not some dotcom startup, so the procedures are in place to make sure that their products don't kill people.
As it turns out, JDK1.1 (along with a native-C library for quick image processing, and a custom PCI card for doing 30MB/sec image transfers) was just fine for the task. We had a team of seven testers working on the project full time for a year, and were able to ship with zero severity 1-2 defects.
We set a new record for lowest defects/KLOC at the customer (a major player in the medical systems industry), despite running JDK 1.1 on Windows NT 4. Our product was several times faster than the C-based product it replaced, had more functionality, and provided more accurate diagnosis for the patient.
Good design is the most important thing in developing good software. The language/runtime/OS can provide crutches to save you if you screw up, but bad design will result in defects no matter how sturdy the crutches are.
I designed and build a diagnostic radiology workstation (in 1997, in Java 1.1, 4x5 megapixel monitors, still in use today). During the development effort we were regaled with stories of software glitches in medical systems resulting in disaster. It really keeps you focused.
In one case, a radiation treatment system had a bug where if you used the backspace key when entering the dose a patient received, the display would show you deleted the last digit, but internally you hadn't. So the patient would recieve 10^backspace times the intended dose of radiation. Not a big deal normally, since the techs would typically shut the machine off between treatments. Until one day when they had two patients needing treatment back to back. The tech knew something was wrong when the machine was running for an unusually long time. The patient knew something was wrong when he died.
On our team a defect that crashed the system was considered severity 2. Severity 1 was reserved for defects that could result in a mis-diagnosis, which most patients agree is worse than a crash.
Picking some arbitrary age limit and saying that you shouldn't do any formal learning after that time is just plain stupid.
I couldn't agree more. What bothers me is the number of people who believe that formal learning needs to be certified in some way. As somebody who doesn't have a degree beyond high school, I spend considerable time each day doing formal learning. Scarily, I know more about computer science than most people I meet who have CS graduate degrees. It's staggering how ignorant many "educated" professionals are of the fundamentals of their field.
A case in point: I recently had to explain the concept of a random number seed to a guy with an MSCS: he somehow thought you needed to initialize the seed each time you wanted a random number. How the hell do you get out of college not understanding pseudo-random number generators? To say nothing of the hoards who don't get big "O" notation.
That's not to say that an undergraduate degree isn't worthwhile for many people, but if you're a very disciplined, self-directed learner, you too may be better off going your own way. In my experience, the degree indicates how good a student you are, not what you know.
I assume that the phone companies and mobile companies have similar (though not identical) issues to this. Aren't they mandated to provide access to their networks to other providers (e.g., Vonage)? What restrictions/costs are typically involved?
Umm, "very dry" at some reasonably high temperature around 20 degrees C, I presume? That's not dry. Try finding out how dry the air gets around -30 C. Yes, we get lots of sparks (we wear sweaters and jackets with nylon linings too), I even get used to touching my car door with my key when I get out (1 cm sparks!) yet somehow the behavior described in the article has never happened.
Do you know why Apple pioneered Command (nee control) Z, X, C, and V for Undo, Cut, Copy, and Paste? Take a look at a QWERTY keyboard: they're the easiest keys to hit with only the left hand. Same for Command-W for close, Q for Quit, and A for select all: one handed operation, leaving the right hand free to drive the mouse.
I grant you, left-handers and non-QWERTY keyboarders are left out in the cold, but at least there was a method to the madness.
o Zip archive o PNG file o JPEG image o ICMP packet o Sendmail envelope (server only, o/c)
All of which have had buffer overflow vulnerabilities, without needing to set any executable bits. And who knows how many other ways I could hide the payload that haven't yet been discovered?
And several buffer overflows (like ICMP) allowed root access on commercial and OSS OSes, so don't give me that "you can't get root" crap.
Granted a shell script would be a bit tougher to hide in there, and my exploit would be arch/os specific, but it's entirely doable: you just need a vulnerability and the right skills to exploit it.
Just let me know if you find any reasonably popular OS available which fits that description. I could easily craft a unix worm in the form of a shell script, with instructions in the email that would trick grandma into running it, and get it running on at least half of all *nix based machines, regardless of vendor. In that script, I'd nohup a simple process which finds a port open and internet-accessible, open a listener on it, and give that listener access to the shell. Then I'd install myself in the user's.*rc file so I could run after a reboot. Profit!
Building a secure OS (where the user can still install their own s/w) is pretty-much agreed to be nowhere near doable these days, so we "burn CPU cycles" dealing with the problems that the developers missed. Seems like an intelligent response to me.
Now, which activity challenges the mind more -- sitting around rooting for the Packers, or managing an entire football franchise through a season of "Madden 2005"...
Let me tell you mister, that rooting for the Packers has been challenging my mind more and more lately...
Does anybody still get spam? Since implementing postgrey, spf, spamassassin, and postfix on an five year old mac worth about $150, I never even receive spam anymore. Postgrey drops over 90% of all spam and viruses before the DATA command, spf and the postfix controls pick off a few more per cent, and SA takes out the rest.
Since configuring amavis to kill all messages with an SA score above 10, I get maybe 1 spam a week that SA wasn't completely sure was spam. I toss that in a shared IMAP folder that any user can write to, and it gets auto-learned as spam within minutes. I never see another message like it again.
Now that this is up and running, I pretty much don't need to touch it except for the occasional bug fix for one of the components.
Why would I bother resorting to vigilantism? The spam problem is solved. Once I added clamav to the mix, viruses went away too.
One of my favorite features of Tiger Server is that I can enable ssh login (and just about every other service including console login) only for the users I choose. That way, even if one of my lusers' accounts is compromised, the bad guys can't get to a command line.
Oh yeah, and I (manually) set their shell to/bin/false. That way if I screw something else up, there's no way anybody's launching a shell as them.
Last, Tiger doesn't have passwords for any of the standard unix accounts, so no amount of dictionary attacking is getting in.
I'm sure most of these features exist for other OS distros, but it's nice that there's GUI access to them in Tiger Server.
The space character (0x20) is the same on both platforms, however. At least MacOS X switched to a more "standard" line terminator (\r\n), however inferior I might feel it is to it's MacOS = 9 equivalent (\r).
Character encoding is truly a bane of modern software. It's kind of like Y2K, but it keeps going on forever, since nobody is going to bother switching legacy systems to support Unicode (and even then, you have multiple choices for encoding).
I take it nobody with a Windows box even tried to view the presentation. All of the space characters are rendered as "x20", which makes it a bit tough (nee impossible) to read.
Try running the anandtech benchmarks against the MySQL that ships with Tiger server instead of the one they compiled with gcc-3.3 (why not use the default compiler, folks?) and you'll see very different numbers.
The reason seems to be that MySQL forks all over the place (an operation that's nearly free on Linux, but expensive on many other unices), so Apple made a few changes that boosted performance enormously.
Yes, there are significant unresolved performance issues with OSX Server, but MySQL performance isn't nearly as bad as the anandtech folks would have you believe.
If you know how to write an assembly language program to wipe out a PC, you will now know how to write an assembly language program to wipe out a Mac.
No, you won't. Because to write an assembly language program to wipe out a PC your program must interact with the OS, and that interaction is completely different between OSes. Even the hooks used by most malware (buffer overruns) would be completely different in almost all cases. Yes, the stack frame would probably look the same, yes the bytecode run by the CPU is the same, but that doesn't really help at all.
Again, if the CPU architecture made it easy to write virii, then there would be linux virii for x86. That hasn't happened, for whatever reason (market share, OS superiority, whatever). Why would MacOS on x86 be any different than Linux x86?
I considered this argument myself for a long time, before reaching this conclustion: Apple knows what happened to OS/2, and is letting it (developers not building "native" apps) happen to MacOS.
Why? Because Steve sees the OS as largely irrelevant from the user's perspective. Apple's customers (notwithstanding us unix geeks) are seeking solutions, not OSes or applications. MacOS happens to be a great OS for enabling solutions, but its the solutions the users give a shit about, not the OS itself.
Let's face it: OSes have become like dial tone: you only really notice when it's missing. People generally don't care if internally Windows is a shitty OS; they care if they can get their work done and get on to other things. Apple understands this, so most of the new features in Tiger are in userland, not in OSland.
Apple's emphasis is making computers that can do what users want, users want to surf, read mail, and run their Windows apps. Guess what? On MacTel, users will be able to do just that. In addition, users can do some other things to make their lives easier: organize photos, music, videos (come on, you know a MacOS-compatible DVR has to be looming). All without needing to worry about malware and security exploits and reinstalling the OS every nine months.
I agree that this news is probably a death blow to many MacOS developers: it's much harder to justify the development and maintenance of MacOS apps now. But I don't think that will hurt Apple at all: people generally don't buy Macs for non-Apple Mac apps. Apple will keep on selling an easy to use, easy to maintain solution for getting your stuff done.
Clearly you have no idea how viruses (or software) actually works. Ask yourself this question: how many Windows viruses spread under Linux? Answer: none. Why? Because the code the virus needs to get its job done is dependent on the OS (Windows).
This reminds me of the days when Apple added PCI cards and the pundits warned of "jumper hell." Think before you write.
I'm going to go way out on a limb here and assume you're under the age of, oh, let's say 30.
Back in the day, sonny, all operating systems shipped in firmware (ROM, EPROM, EEPROM, etc.). The Apple ][ had everything in ROM except the code needed to run the file system (hence the name DOS: Disk Operating System, as in a system to run the disk). Everything else was in ROM: the BASIC interpreter, the... well, there wasn't much else out there at the time.
The Macintosh was notable in its day partly because it had 128K of ROM, and that stored pretty much everything you needed to get programs to run: QuickDraw, the memory management, everything was stored in ROM so you didn't need to waste space on a floppy.
Slashdot Mirror
Actually, not true for AJAX, if well-implemented.
I've been working with JsOrb (which lets you call your Java interfaces from Javascript) and one of the nice things about it is that when used correctly it makes XSS vulnerabilities go away. Since the data is encoded inside XML messages, the browser takes care of properly escaping all those goofy characters into & for you.
Never did I think I'd actually be glad to be a Qwest customer. I mean, after all the rolling over that Qwest has done, all the anti-customer behavior, I'm surprised they took the moral high ground.
Oh, wait. They didn't, they were just afraid they'd get sued.
I remember having being burnt by a GC bug in 1.1.7 (can't remember exactly which version it was in 98 I think) where the GC would remove objects when they were only referred by a static handle (classic singleton pattern).
Holy cow I remember that bug! You needed to use the -noclassgc option to keep it from happening.
While I agree that when using a new system you'll find more bugs, it doesn't mean that you need to do any less testing on an older, more "established" system. That's the mistake made on several of the bugs in the article: they assumed that since the underlying components were used before, they must be stable.
It was a GUI/workflow app, not a hardware control system. Diagnostic Radiology is when a radiologist is looking at your images (think of the digital equivalent of a lightbox on the wall). Our system could bring up the patient's historical exams (useful for cancer patients), cross-reference exams in different orientations (coronal, saggital, and axial), make annotations, and dictate a diagnosis into an automated dictation system.
Radiation treatment is the kind of system where there's a gun to turn on/off. This is a system some friends of mine have built that is truly amazing. If you have a lung tumor near the spine, this thing takes into account your lungs' expansion while you breathe (in realtime) as it administers the dose. The math is, umm, a bit stunning.
It really doesn't matter what language you use: bugs can be written in any of them. In this case, the customer wanted a GUI workstation running on Windows, with the possibility of being cross-platform. Java was new and cool (1.1 had been out for six week when we started), and they decided to give it a shot. This is a company with fifty years experience in medical systems, not some dotcom startup, so the procedures are in place to make sure that their products don't kill people.
As it turns out, JDK1.1 (along with a native-C library for quick image processing, and a custom PCI card for doing 30MB/sec image transfers) was just fine for the task. We had a team of seven testers working on the project full time for a year, and were able to ship with zero severity 1-2 defects.
We set a new record for lowest defects/KLOC at the customer (a major player in the medical systems industry), despite running JDK 1.1 on Windows NT 4. Our product was several times faster than the C-based product it replaced, had more functionality, and provided more accurate diagnosis for the patient.
Good design is the most important thing in developing good software. The language/runtime/OS can provide crutches to save you if you screw up, but bad design will result in defects no matter how sturdy the crutches are.
I designed and build a diagnostic radiology workstation (in 1997, in Java 1.1, 4x5 megapixel monitors, still in use today). During the development effort we were regaled with stories of software glitches in medical systems resulting in disaster. It really keeps you focused.
In one case, a radiation treatment system had a bug where if you used the backspace key when entering the dose a patient received, the display would show you deleted the last digit, but internally you hadn't. So the patient would recieve 10^backspace times the intended dose of radiation. Not a big deal normally, since the techs would typically shut the machine off between treatments. Until one day when they had two patients needing treatment back to back. The tech knew something was wrong when the machine was running for an unusually long time. The patient knew something was wrong when he died.
On our team a defect that crashed the system was considered severity 2. Severity 1 was reserved for defects that could result in a mis-diagnosis, which most patients agree is worse than a crash.
I couldn't agree more. What bothers me is the number of people who believe that formal learning needs to be certified in some way. As somebody who doesn't have a degree beyond high school, I spend considerable time each day doing formal learning. Scarily, I know more about computer science than most people I meet who have CS graduate degrees. It's staggering how ignorant many "educated" professionals are of the fundamentals of their field.
A case in point: I recently had to explain the concept of a random number seed to a guy with an MSCS: he somehow thought you needed to initialize the seed each time you wanted a random number. How the hell do you get out of college not understanding pseudo-random number generators? To say nothing of the hoards who don't get big "O" notation.
That's not to say that an undergraduate degree isn't worthwhile for many people, but if you're a very disciplined, self-directed learner, you too may be better off going your own way. In my experience, the degree indicates how good a student you are, not what you know.
I assume that the phone companies and mobile companies have similar (though not identical) issues to this. Aren't they mandated to provide access to their networks to other providers (e.g., Vonage)? What restrictions/costs are typically involved?
Umm, "very dry" at some reasonably high temperature around 20 degrees C, I presume? That's not dry. Try finding out how dry the air gets around -30 C. Yes, we get lots of sparks (we wear sweaters and jackets with nylon linings too), I even get used to touching my car door with my key when I get out (1 cm sparks!) yet somehow the behavior described in the article has never happened.
Time for snopes.
Do you know why Apple pioneered Command (nee control) Z, X, C, and V for Undo, Cut, Copy, and Paste? Take a look at a QWERTY keyboard: they're the easiest keys to hit with only the left hand. Same for Command-W for close, Q for Quit, and A for select all: one handed operation, leaving the right hand free to drive the mouse.
I grant you, left-handers and non-QWERTY keyboarders are left out in the cold, but at least there was a method to the madness.
No, it's pronounced "Roker" as in "Al Roker." Rokerphone. Free weather updates on the hour, every hour. Oh, and something about music. WEATHER!
And I suppose we can expect the phones we buy today to be half the thickness and half the weight in a few years?
I'd put my exploit inside a malformed...
o Zip archive
o PNG file
o JPEG image
o ICMP packet
o Sendmail envelope (server only, o/c)
All of which have had buffer overflow vulnerabilities, without needing to set any executable bits. And who knows how many other ways I could hide the payload that haven't yet been discovered?
And several buffer overflows (like ICMP) allowed root access on commercial and OSS OSes, so don't give me that "you can't get root" crap.
Granted a shell script would be a bit tougher to hide in there, and my exploit would be arch/os specific, but it's entirely doable: you just need a vulnerability and the right skills to exploit it.
Just let me know if you find any reasonably popular OS available which fits that description. I could easily craft a unix worm in the form of a shell script, with instructions in the email that would trick grandma into running it, and get it running on at least half of all *nix based machines, regardless of vendor. In that script, I'd nohup a simple process which finds a port open and internet-accessible, open a listener on it, and give that listener access to the shell. Then I'd install myself in the user's .*rc file so I could run after a reboot. Profit!
Building a secure OS (where the user can still install their own s/w) is pretty-much agreed to be nowhere near doable these days, so we "burn CPU cycles" dealing with the problems that the developers missed. Seems like an intelligent response to me.
Now, which activity challenges the mind more -- sitting around rooting for the Packers, or managing an entire football franchise through a season of "Madden 2005"...
Let me tell you mister, that rooting for the Packers has been challenging my mind more and more lately...
Does anybody still get spam? Since implementing postgrey, spf, spamassassin, and postfix on an five year old mac worth about $150, I never even receive spam anymore. Postgrey drops over 90% of all spam and viruses before the DATA command, spf and the postfix controls pick off a few more per cent, and SA takes out the rest.
Since configuring amavis to kill all messages with an SA score above 10, I get maybe 1 spam a week that SA wasn't completely sure was spam. I toss that in a shared IMAP folder that any user can write to, and it gets auto-learned as spam within minutes. I never see another message like it again.
Now that this is up and running, I pretty much don't need to touch it except for the occasional bug fix for one of the components.
Why would I bother resorting to vigilantism? The spam problem is solved. Once I added clamav to the mix, viruses went away too.
One of my favorite features of Tiger Server is that I can enable ssh login (and just about every other service including console login) only for the users I choose. That way, even if one of my lusers' accounts is compromised, the bad guys can't get to a command line.
/bin/false. That way if I screw something else up, there's no way anybody's launching a shell as them.
Oh yeah, and I (manually) set their shell to
Last, Tiger doesn't have passwords for any of the standard unix accounts, so no amount of dictionary attacking is getting in.
I'm sure most of these features exist for other OS distros, but it's nice that there's GUI access to them in Tiger Server.
The space character (0x20) is the same on both platforms, however. At least MacOS X switched to a more "standard" line terminator (\r\n), however inferior I might feel it is to it's MacOS = 9 equivalent (\r).
Character encoding is truly a bane of modern software. It's kind of like Y2K, but it keeps going on forever, since nobody is going to bother switching legacy systems to support Unicode (and even then, you have multiple choices for encoding).
Weird. I'm running XP SP2 on a stock HP, and no such luck. Guess I'll try it from my Mac when I get home.
I take it nobody with a Windows box even tried to view the presentation. All of the space characters are rendered as "x20", which makes it a bit tough (nee impossible) to read.
Your sig says it all: ignorance is bliss.
Try running the anandtech benchmarks against the MySQL that ships with Tiger server instead of the one they compiled with gcc-3.3 (why not use the default compiler, folks?) and you'll see very different numbers.
The reason seems to be that MySQL forks all over the place (an operation that's nearly free on Linux, but expensive on many other unices), so Apple made a few changes that boosted performance enormously.
Yes, there are significant unresolved performance issues with OSX Server, but MySQL performance isn't nearly as bad as the anandtech folks would have you believe.
If you know how to write an assembly language program to wipe out a PC, you will now know how to write an assembly language program to wipe out a Mac.
No, you won't. Because to write an assembly language program to wipe out a PC your program must interact with the OS, and that interaction is completely different between OSes. Even the hooks used by most malware (buffer overruns) would be completely different in almost all cases. Yes, the stack frame would probably look the same, yes the bytecode run by the CPU is the same, but that doesn't really help at all.
Again, if the CPU architecture made it easy to write virii, then there would be linux virii for x86. That hasn't happened, for whatever reason (market share, OS superiority, whatever). Why would MacOS on x86 be any different than Linux x86?
Think more before you post.
I considered this argument myself for a long time, before reaching this conclustion: Apple knows what happened to OS/2, and is letting it (developers not building "native" apps) happen to MacOS.
Why? Because Steve sees the OS as largely irrelevant from the user's perspective. Apple's customers (notwithstanding us unix geeks) are seeking solutions, not OSes or applications. MacOS happens to be a great OS for enabling solutions, but its the solutions the users give a shit about, not the OS itself.
Let's face it: OSes have become like dial tone: you only really notice when it's missing. People generally don't care if internally Windows is a shitty OS; they care if they can get their work done and get on to other things. Apple understands this, so most of the new features in Tiger are in userland, not in OSland.
Apple's emphasis is making computers that can do what users want, users want to surf, read mail, and run their Windows apps. Guess what? On MacTel, users will be able to do just that. In addition, users can do some other things to make their lives easier: organize photos, music, videos (come on, you know a MacOS-compatible DVR has to be looming). All without needing to worry about malware and security exploits and reinstalling the OS every nine months.
I agree that this news is probably a death blow to many MacOS developers: it's much harder to justify the development and maintenance of MacOS apps now. But I don't think that will hurt Apple at all: people generally don't buy Macs for non-Apple Mac apps. Apple will keep on selling an easy to use, easy to maintain solution for getting your stuff done.
Clearly you have no idea how viruses (or software) actually works. Ask yourself this question: how many Windows viruses spread under Linux? Answer: none. Why? Because the code the virus needs to get its job done is dependent on the OS (Windows).
This reminds me of the days when Apple added PCI cards and the pundits warned of "jumper hell." Think before you write.
Will this be the real end of innovation in videogames?
No, that happened a long time ago. I can't remember the last innovative video game I've seen. Probably SimCity (the original one).
I'm going to go way out on a limb here and assume you're under the age of, oh, let's say 30.
Back in the day, sonny, all operating systems shipped in firmware (ROM, EPROM, EEPROM, etc.). The Apple ][ had everything in ROM except the code needed to run the file system (hence the name DOS: Disk Operating System, as in a system to run the disk). Everything else was in ROM: the BASIC interpreter, the... well, there wasn't much else out there at the time.
The Macintosh was notable in its day partly because it had 128K of ROM, and that stored pretty much everything you needed to get programs to run: QuickDraw, the memory management, everything was stored in ROM so you didn't need to waste space on a floppy.