On a related note - would you sign up on this ISP?
I think you'll want to go for a slightly less technical savvy clientele, unless you're looking at a market that is currently charged by data throughput.
What is the benefit to me if the ads are blocked automatically by the ISP rather than automatically by my computer?
The software industry is dead. There is no more money to be had here. Switch majors now, do not seek a job in computing. Really, it's for your own good.;)
Read the other reply to my post dude, it makes exactly the same point. (and I guess the ANNOUNCE does too...)
If the ascii-armored code ever refers to parameters via a register that the user code pops from the stack, you *can* pass parameters. (like if it uses a standard stack frame) It's much more difficult though.
Which is why the area is slightly larger than 16MB.
I don't understand this... "slightly larger" as in until the end of the last function or what? and what does this have to do with parameters?
Ah, good point. You'd have to rely on the parameters you need starting as the second argument of the call with the buffer overflow, which is probably fairly rare.
Or, if the buggy code and the system call use a stack frame and you can jump past the setup for that, you can move ebp so its parameters come from somewhere else. I imagine there's probably ways of preventing that without modifying the user code.
It's very clever, makes it much harder to exploit.
Well apparently it deals with that as well, by moving system libraries to an "ASCII-armor" area from 0x00000000-0x00ffffff. This is supposed to be safe since ASCIIZ strings can't contain 0s....but I think there's a flaw with that, ASCIIz strings will always contain *one* 0, the terminating one. Since x86 stores addresses as little endian, the high byte in the address will be the last byte in memory. If you arrange for the terminating NULL to be at the last byte of the return address, you can jump to that "ASCII armor" area, since the string will overwrite the lower bytes.
I dunno if I'm understanding their intention correctly tho.
For string/array copies, the difference is negligable (but it is there). Where you have risk of some remotely significant speed difference is checking bounds on every array access.
More likely it's because strcpy et al take two arguments and anything that checks the length of the buffer must take at least three.
i suppose you are referring to the case where some input explicitely specifies an invalid array-index.
There are a number of cases where this can happen, all of which can be blocked. You can block them once, when you get the input from the user, or you can block them at every memory reference.
yes, but you can not guarantee that all this is done - and without making mistakes.
How do you know? Even if you hand code the checks everywhere, it is entirely possible to get all of them right. Programming time could get prohibitively expensive, but it is possible.
OTOH, I could write my own string/array copy routines that would make it similarly difficult to create a buffer overflow vulnerability. As long as you don't code drunk, no problem.
different to dynamic strings/arrays and automatic index checking, which are a no-brainer to use.
And you could do that, too. You can, in the language you're already using, add automatic index checking, etc. (or use a premade library) It might be a little awkward, but it can be done, and then you don't have to rewrite everything else.
Are there any real programs that ever modify their own code, or compilers that output code that does so?
Self-modifying code is used a lot less on modern processors because the CPU tries to look into the future assuming that the code doesn't change. If you change the code too close to it being executed, it throws off pipelining, branch prediction, etc and really hurts performance.
There's the other kind, where you basically have a compiler in your program, compile a whole subroutine and call it, and in this case you don't need write and execute at the same time. You always finish writing it before it's executed.
this does not prevent the buffer overflow. it just makes the program terminate instead.
That depends on the exploit. If the attacker can find the address for system calls, he can write a function call onto the stack that will activate on return. That's potentially more difficult tho, especially with systrace.
so you trade being rooted with denial-of-service.
Not the best, but an extremely valuable trade.
to actually prevent the buffer overflow, you need to code in a language with dynamic strings and arrays.
Nonsense. To prevent the buffer overflow, you have to make sure not to copy more into the buffer than it will hold. Nothing more, nothing less.
Dynamic strings and arrays can help, since you can make the buffer as big as your data, but you can still overflow a dynamic array if you never check the data size.
Furthermore, you don't need dynamic arrays, nor do you need built-in language support. I have written (trivial) programs in C that use fixed buffers, don't truncate input, and are immune to buffer overflow attacks. In most cases it's easier to go with dynamic arrays, which even C supports, tho perhaps not in the way you intend.
The only thing you need to prevent buffer overflows is to check the size of all data from untrusted sources before you put it in your buffer.
Does no-one actually bother to analyze the economics here?
Analyzing the economics and excusing companies like that breaks capitalism. It's understandable that HP would do this, that doesn't mean you should forgive them and still buy their products. Whose fault it is is irrelevant, if you buy it, it will get worse.
You're wrong anyway. HP could sell the printers for $499 and give away the ink. Some people would even take advantage of it. They would make less of a profit, but they have that choice.
I'll take closing and re-opening a file over having to restart the application.
Huh? What makes you think that's an option, and how would it make any sense?
It writes corrupted data. You are not aware of this. You close the file. You open it again, maybe a few days later. You find out your hard work is hopelessly lost.
vs.
It crashes. You are immediately aware of this. You reopen the app and the file. Maybe you've lost back to the last time you saved, at most.
When the barcode scanner reads the barcode, it must know when to start reading and stop reading, and it does this by finding the code "101" you see at the beginning and end of the barcode. Also, in the middle of every UPC is a 01010 combination, which basically tells the scanner that it has reached the middle of the barcode.
The code on the ends is *not* 101, neither is the code in the middle 01010. Think of it more as ternary (or maybe base 4, I'm not up on my UPC trivia) encoded in the width of the bars, it's 000 or 00000. The proper code for a 6 is something like 0003.
Each number in a UPC barcode is represented by 4 stripes. White/black is irrelevant to the number itself, the barcode has to alternate black and white, and the right half is inverted (or the left depending on your point of view)
Data is encoded not in the color, but in the width of each bar. There are three (I think, maybe four) bar widths, narrow, medium, and wide. Three narrow bars and a wide one represent a 6. If there is no wide bar, it is not a 6.
There are four narrow bars on either end, and five in the center for synchronizing the scanner to the code. You wouldn't interpret the start, stop, and parity bits on a serial port as data, would you?
Actually Java and.NET bytecode style applications are likely to beable to be better optimized than their C and C++ equivelants with a decent virtual machine when running on Itanium.
They'll definitely compare favorably if you consider that Java and.NET are already translated on the x86 while it would be new overhead for C and C++ code. (Assuming that your VM is itself natively compiled.)
Java and.NET were also designed to be translated whereas x86 wasn't, which gets into what you're saying.
another thing i used to do back in the DOS days is use the ascii character 255 in filenames... it's legal in a filename... but it looks exactly like a space on the console; most people are none the wiser when they saw a file with no name.
No, no, no. You don't create it with just 255 in the name, you take an existing name and add duplicates with 255's attached to the end.
Yes, there are now 6 "DOS" directories on your machine.
Slashdot Mirror
On a related note - would you sign up on this ISP?
I think you'll want to go for a slightly less technical savvy clientele, unless you're looking at a market that is currently charged by data throughput.
What is the benefit to me if the ads are blocked automatically by the ISP rather than automatically by my computer?
That means faster download speeds. The RedHat 9 ISO files were downloading at over 120KB/sec on Freenet.
At this very moment I am getting this file at over 200kB/sec from BitTorrent.
Shut up!
;)
The software industry is dead. There is no more money to be had here. Switch majors now, do not seek a job in computing. Really, it's for your own good.
Good idea or not, it isn't happening (and didn't happen years ago when he was pushing it). Ellison is not exactly a visionary.
Read the other reply to my post dude, it makes exactly the same point. (and I guess the ANNOUNCE does too...)
If the ascii-armored code ever refers to parameters via a register that the user code pops from the stack, you *can* pass parameters. (like if it uses a standard stack frame) It's much more difficult though.
Which is why the area is slightly larger than 16MB.
I don't understand this... "slightly larger" as in until the end of the last function or what? and what does this have to do with parameters?
Maybe it goes through 0x01010100?
Ah, good point. You'd have to rely on the parameters you need starting as the second argument of the call with the buffer overflow, which is probably fairly rare.
Or, if the buggy code and the system call use a stack frame and you can jump past the setup for that, you can move ebp so its parameters come from somewhere else. I imagine there's probably ways of preventing that without modifying the user code.
It's very clever, makes it much harder to exploit.
Well apparently it deals with that as well, by moving system libraries to an "ASCII-armor" area from 0x00000000-0x00ffffff. This is supposed to be safe since ASCIIZ strings can't contain 0s. ...but I think there's a flaw with that, ASCIIz strings will always contain *one* 0, the terminating one. Since x86 stores addresses as little endian, the high byte in the address will be the last byte in memory. If you arrange for the terminating NULL to be at the last byte of the return address, you can jump to that "ASCII armor" area, since the string will overwrite the lower bytes.
I dunno if I'm understanding their intention correctly tho.
For string/array copies, the difference is negligable (but it is there). Where you have risk of some remotely significant speed difference is checking bounds on every array access.
More likely it's because strcpy et al take two arguments and anything that checks the length of the buffer must take at least three.
i suppose you are referring to the case where some input explicitely specifies an invalid array-index.
There are a number of cases where this can happen, all of which can be blocked. You can block them once, when you get the input from the user, or you can block them at every memory reference.
yes, but you can not guarantee that all this is done - and without making mistakes.
How do you know? Even if you hand code the checks everywhere, it is entirely possible to get all of them right. Programming time could get prohibitively expensive, but it is possible.
OTOH, I could write my own string/array copy routines that would make it similarly difficult to create a buffer overflow vulnerability. As long as you don't code drunk, no problem.
different to dynamic strings/arrays and automatic index checking, which are a no-brainer to use.
And you could do that, too. You can, in the language you're already using, add automatic index checking, etc. (or use a premade library) It might be a little awkward, but it can be done, and then you don't have to rewrite everything else.
Are there any real programs that ever modify their own code, or compilers that output code that does so?
Self-modifying code is used a lot less on modern processors because the CPU tries to look into the future assuming that the code doesn't change. If you change the code too close to it being executed, it throws off pipelining, branch prediction, etc and really hurts performance.
There's the other kind, where you basically have a compiler in your program, compile a whole subroutine and call it, and in this case you don't need write and execute at the same time. You always finish writing it before it's executed.
this does not prevent the buffer overflow. it just makes the program terminate instead.
That depends on the exploit. If the attacker can find the address for system calls, he can write a function call onto the stack that will activate on return. That's potentially more difficult tho, especially with systrace.
so you trade being rooted with denial-of-service.
Not the best, but an extremely valuable trade.
to actually prevent the buffer overflow, you need to code in a language with dynamic strings and arrays.
Nonsense. To prevent the buffer overflow, you have to make sure not to copy more into the buffer than it will hold. Nothing more, nothing less.
Dynamic strings and arrays can help, since you can make the buffer as big as your data, but you can still overflow a dynamic array if you never check the data size.
Furthermore, you don't need dynamic arrays, nor do you need built-in language support. I have written (trivial) programs in C that use fixed buffers, don't truncate input, and are immune to buffer overflow attacks. In most cases it's easier to go with dynamic arrays, which even C supports, tho perhaps not in the way you intend.
The only thing you need to prevent buffer overflows is to check the size of all data from untrusted sources before you put it in your buffer.
The demand for replacement monitors would increase dramatically...
Does no-one actually bother to analyze the economics here?
Analyzing the economics and excusing companies like that breaks capitalism. It's understandable that HP would do this, that doesn't mean you should forgive them and still buy their products. Whose fault it is is irrelevant, if you buy it, it will get worse.
You're wrong anyway. HP could sell the printers for $499 and give away the ink. Some people would even take advantage of it. They would make less of a profit, but they have that choice.
I'll take closing and re-opening a file over having to restart the application.
Huh? What makes you think that's an option, and how would it make any sense?
It writes corrupted data. You are not aware of this. You close the file. You open it again, maybe a few days later. You find out your hard work is hopelessly lost.
vs.
It crashes. You are immediately aware of this. You reopen the app and the file. Maybe you've lost back to the last time you saved, at most.
Uh oh, looks like they're pulling ahead...
Mr. Flibble's very cross!
When the barcode scanner reads the barcode, it must know when to start reading and stop reading, and it does this by finding the code "101" you see at the beginning and end of the barcode. Also, in the middle of every UPC is a 01010 combination, which basically tells the scanner that it has reached the middle of the barcode.
The code on the ends is *not* 101, neither is the code in the middle 01010. Think of it more as ternary (or maybe base 4, I'm not up on my UPC trivia) encoded in the width of the bars, it's 000 or 00000. The proper code for a 6 is something like 0003.
Each number in a UPC barcode is represented by 4 stripes. White/black is irrelevant to the number itself, the barcode has to alternate black and white, and the right half is inverted (or the left depending on your point of view)
Data is encoded not in the color, but in the width of each bar. There are three (I think, maybe four) bar widths, narrow, medium, and wide. Three narrow bars and a wide one represent a 6. If there is no wide bar, it is not a 6.
There are four narrow bars on either end, and five in the center for synchronizing the scanner to the code. You wouldn't interpret the start, stop, and parity bits on a serial port as data, would you?
it does not support alpha blending
It does, but you have to do bizzare filter things in the html. Why they don't make it automatic is beyond me.
Forget the bank analogy then. It's still true.
Would you rather have your text editor hit a bug and write random garbage over your term paper, or would you rather it just crash?
Actually Java and .NET bytecode style applications are likely to beable to be better optimized than their C and C++ equivelants with a decent virtual machine when running on Itanium.
.NET are already translated on the x86 while it would be new overhead for C and C++ code. (Assuming that your VM is itself natively compiled.)
.NET were also designed to be translated whereas x86 wasn't, which gets into what you're saying.
They'll definitely compare favorably if you consider that Java and
Java and
But Flash RAM can only be written/erased a few thousand times.
iirc, it's a hundred thousand to a million times. Mind you, I'd still perfer much higher for mass storage.
People got pissed when hard disk warranties went down to a year - how will they feel when a disk wears out in months?
What part of the drive do you write to that often, other than swap space?
As for swap, think about it. If memory is cheap enough to use as mass storage, would you need swap?
re mlush's price point, "as a price point on flash RAM USB key drives are about 1$/Mb":
CF cards are under $.20/MB
Sim City has had this for years...
Nah, this isn't available until 2020 in Sim City.
B) Try doing that in DOS.
/s /p "text" "c:\path\*"
I don't have DOS, but I have the Windows 2000 command line, do I still get a cookie?
findstr
another thing i used to do back in the DOS days is use the ascii character 255 in filenames... it's legal in a filename... but it looks exactly like a space on the console; most people are none the wiser when they saw a file with no name.
No, no, no. You don't create it with just 255 in the name, you take an existing name and add duplicates with 255's attached to the end.
Yes, there are now 6 "DOS" directories on your machine.
Err... never mind.
makes me wonder where they got the info for this graph tho...