oh.. I see what you're saying here! If you had a descriptor in CS that only includes the code segment of the executable (and any libraries) then execution in the data segments would be impossible. There's a few issues here that you would have to iron out, like placements of the code segments so that they are serialized in memory and don't have any data between them, but yes, I suppose this could work. I'll have a look at it.
that's leet! But I say sooner! Let's get the gui up and running before the filesystems are even mounted. Before the harddrive drivers are even initialized! Put the gui in the kernel. Start it on bootup then push it back out to usermode. Get rid of kernel compression and make sure the kernel is taking up contiguous sectors on the harddrive. Get the bios to load track by track the entire thing straight into memory. Ok.. maybe this wouldn't be the fastest, maybe we need to start the framebuffer driver, then the harddrive driver, then load the gui from some precompiled locations on the disk and get it rollin' in userland before we start initializing all the other drivers.
You're totally wrong. If the only type of data segments you have are execute-only and execute-read then how exactly do we have read-write-execute segments? Obviously we have them, or we wouldn't be having this discussion. Actually the only thing that makes a descriptor an "executable descriptor" is that it is currently residing in CS. Oh, and if you can show me a way to resolve pointer references to the right descriptor (is it in DS or is it in SS) with any sort of efficency, or security for that mater, I'd love to see it. Think about it. You have a piece of code like:
char *p;
...
*(p++) = 'A';
...
Now how do you know that p is pointing to the data segment or to the stack segment? You can't. Maybe you can define a new kind of pointer (called a "far" pointer in borland compilers) that contains the segment descriptor in the pointer. But unfortunately you'll have to get the segment descriptor out of the pointer and put it into a segment register before you can do it.
Here's an idea.. rather than display a cute image for no apparent reason, how about actually starting the gui up and letting me do something whilst the system loads? For example, the first few seconds of my linux boot up start up the drivers etc and eventually start init. Now if my init was my desktop application (eazel, kde, whatever) then I could have the screen and the mouse all in the right mode and ready to go at the instant that it actually starts. Then the first thing my desktop app can do is start all those daemons and run all those network startup scripts and give me a nice gui display that I can ignore if I want and go off and start working.
umm.. no.. see security analysis is a completely different disciplin to software development. So what you're asking the programmers to do is something very very hard (for them). You might as well ask them to determine if there is a product for the software or whip up an ad campaign for it. After all, who knows the product better than the software developers right? Now.. a reasonably informed opinion would be that companies should get security testers to test their product before they ship (or better yet, during the development cycle). But that would involve hiring people and paying them money to fix problems that people might not even find. Remember, most security bugs are not found. The product lives out its short life and disappears from the world when the next version or the next great paradigm shift happens. So you're asking companies to spend money on things that don't really loose them any money in the long run. So no, there is no technical reason why software can't be secure. It's an economic/political thing.
suprisingly not.. I'll give it my best shot. Latte, I say "lar" as in "large" followed by "tay" as in "taylor" but americians might just say "la" as in "latin" followed by "tay".
actually it's even worse than that. On an x86, you have two mechanisms of protection. You have segmented protection and you have page level protection. On page level protection you may specify whether a page is readable, writable or both. If a page is readable then it is executable. The other form of protection is descritor level protection. That is, the descriptor used in the segment registers (mapped via the LDT and GDT) can be set to, once again, readable or writable or both. Readable implies executable. Now this is so engrained in x86 that you will often see people refering to the readable bit as "read-exec". Linux uses descriptors via the LDT of each process to give seperate address spaces to every program. However, the stack is not a seperate address space to the code and data segments. That is, you don't have a different descriptor in SS than you do in DS. If you did have such a mechanism, you would have a lot of problems deciding when you need to use the SS register and when you need to use the DS register to access pointers.
you assume that I want you to read my web site. Perhaps I don't want anyone to be able to read my website except people who are willing to download the flash plugin and are using IE. Perhaps I have come to this decision after looking at marketing stats and determining that comments posted on my web site by people who refuse to download the plugin or use IE are detrimental to my market. Or perhaps I don't really care if the minority of users not using IE can't read my web site. Hell, maybe the only reason people are comming to my web site is to see my kickass flash animations!
this was hardly a case of a strcpy into a stack buffer. Read the article. This was not the kind of buffer overflow that could be fixed with a library. Indeed, a language that did bounds checking on arrays (and completely didn't support pointers) could have avoided this problem, but I'm not sure that it would.
this is still in existance for the sole reason that no-one has bothered to write an exploit for it. In situations like this the standard response is to create a web page that explains what the exploit does and how it will do it. Then a link is included that says "show me, I want to be exploited" and clicking on the link does something fancy like writing files to your harddrive or desktop along with bringing up a message box. Why is this necessary? Because most companies do not have the time or man power to track down every little bug and fix it, not matter the security risk and it is only after demonstrating that this is a serious problem that customers start to complain and companies take notice.
err.. you're really lost in thinking that this code is being executed in the data segment but anyways, on x86 there is only READ_EXEC_ONLY, READ_WRITE_EXEC, READ_ONLY or NO_PERMISSIONS. You can't say READ_WRITE_ONLY which is the problem. If you want a data section that is read only then you can have that, but if you want a read/write data section that is not executable, sorry, that's not offered.
oh please. Firstly, the majority of Mac users have heard so much bad news about OS X that they don't want to go near it and secondly, Photoshop users are not the exception, they're the core market!
of course not. But they could give it a good go. Unfortunately they would be stuck on a command line because when the question comes up "What are the vrefresh and vsync rates for your monitor?" they would have no clue. Am I the only one who doesn't immediately scramble for the monitor manual on the first day that I buy a new monitor and write these numbers above the screen? WTF is with that?
shouldn't that be tar.gz + reading the web page / README to determine what other crap you have to have installed before some trivial util you download will work? Most of us who use apt-get and rpm actually have a reason for doing so, because it includes dependancy information.
I installed mojonation on my brother's computer and he asked me what it was. I explained the concept to him and he's like "You mean I could be storing ANYTHING on my computer and I don't know what it is?" and I had to agree. This appears to be the opinion.
Slashdot Mirror
oh.. I see what you're saying here! If you had a descriptor in CS that only includes the code segment of the executable (and any libraries) then execution in the data segments would be impossible. There's a few issues here that you would have to iron out, like placements of the code segments so that they are serialized in memory and don't have any data between them, but yes, I suppose this could work. I'll have a look at it.
hehehe.. I say "la" as "lar" (or perhaps "lah") don't you?
that's leet! But I say sooner! Let's get the gui up and running before the filesystems are even mounted. Before the harddrive drivers are even initialized! Put the gui in the kernel. Start it on bootup then push it back out to usermode. Get rid of kernel compression and make sure the kernel is taking up contiguous sectors on the harddrive. Get the bios to load track by track the entire thing straight into memory. Ok.. maybe this wouldn't be the fastest, maybe we need to start the framebuffer driver, then the harddrive driver, then load the gui from some precompiled locations on the disk and get it rollin' in userland before we start initializing all the other drivers.
You're totally wrong. If the only type of data segments you have are execute-only and execute-read then how exactly do we have read-write-execute segments? Obviously we have them, or we wouldn't be having this discussion. Actually the only thing that makes a descriptor an "executable descriptor" is that it is currently residing in CS. Oh, and if you can show me a way to resolve pointer references to the right descriptor (is it in DS or is it in SS) with any sort of efficency, or security for that mater, I'd love to see it. Think about it. You have a piece of code like:
char *p;
...
*(p++) = 'A';
...
Now how do you know that p is pointing to the data segment or to the stack segment? You can't. Maybe you can define a new kind of pointer (called a "far" pointer in borland compilers) that contains the segment descriptor in the pointer. But unfortunately you'll have to get the segment descriptor out of the pointer and put it into a segment register before you can do it.
Here's an idea.. rather than display a cute image for no apparent reason, how about actually starting the gui up and letting me do something whilst the system loads? For example, the first few seconds of my linux boot up start up the drivers etc and eventually start init. Now if my init was my desktop application (eazel, kde, whatever) then I could have the screen and the mouse all in the right mode and ready to go at the instant that it actually starts. Then the first thing my desktop app can do is start all those daemons and run all those network startup scripts and give me a nice gui display that I can ignore if I want and go off and start working.
how about posting how to do this under win2k.
umm.. no.. see security analysis is a completely different disciplin to software development. So what you're asking the programmers to do is something very very hard (for them). You might as well ask them to determine if there is a product for the software or whip up an ad campaign for it. After all, who knows the product better than the software developers right? Now.. a reasonably informed opinion would be that companies should get security testers to test their product before they ship (or better yet, during the development cycle). But that would involve hiring people and paying them money to fix problems that people might not even find. Remember, most security bugs are not found. The product lives out its short life and disappears from the world when the next version or the next great paradigm shift happens. So you're asking companies to spend money on things that don't really loose them any money in the long run. So no, there is no technical reason why software can't be secure. It's an economic/political thing.
suprisingly not.. I'll give it my best shot. Latte, I say "lar" as in "large" followed by "tay" as in "taylor" but americians might just say "la" as in "latin" followed by "tay".
but he is just a persian cat and a monocle away from being a james bond villian.
actually it's even worse than that. On an x86, you have two mechanisms of protection. You have segmented protection and you have page level protection. On page level protection you may specify whether a page is readable, writable or both. If a page is readable then it is executable. The other form of protection is descritor level protection. That is, the descriptor used in the segment registers (mapped via the LDT and GDT) can be set to, once again, readable or writable or both. Readable implies executable. Now this is so engrained in x86 that you will often see people refering to the readable bit as "read-exec". Linux uses descriptors via the LDT of each process to give seperate address spaces to every program. However, the stack is not a seperate address space to the code and data segments. That is, you don't have a different descriptor in SS than you do in DS. If you did have such a mechanism, you would have a lot of problems deciding when you need to use the SS register and when you need to use the DS register to access pointers.
The kernel is coded to be portable. On some archetectures you can indeed say this, but not on x86.
you assume that I want you to read my web site. Perhaps I don't want anyone to be able to read my website except people who are willing to download the flash plugin and are using IE. Perhaps I have come to this decision after looking at marketing stats and determining that comments posted on my web site by people who refuse to download the plugin or use IE are detrimental to my market. Or perhaps I don't really care if the minority of users not using IE can't read my web site. Hell, maybe the only reason people are comming to my web site is to see my kickass flash animations!
this was hardly a case of a strcpy into a stack buffer. Read the article. This was not the kind of buffer overflow that could be fixed with a library. Indeed, a language that did bounds checking on arrays (and completely didn't support pointers) could have avoided this problem, but I'm not sure that it would.
some how I doubt the first exploit to be written for this bug will be targeting linux.
Actually you can get the source to the Macromedia Flash (ie Shockwave) player at no cost.
this is still in existance for the sole reason that no-one has bothered to write an exploit for it. In situations like this the standard response is to create a web page that explains what the exploit does and how it will do it. Then a link is included that says "show me, I want to be exploited" and clicking on the link does something fancy like writing files to your harddrive or desktop along with bringing up a message box. Why is this necessary? Because most companies do not have the time or man power to track down every little bug and fix it, not matter the security risk and it is only after demonstrating that this is a serious problem that customers start to complain and companies take notice.
err.. you're really lost in thinking that this code is being executed in the data segment but anyways, on x86 there is only READ_EXEC_ONLY, READ_WRITE_EXEC, READ_ONLY or NO_PERMISSIONS. You can't say READ_WRITE_ONLY which is the problem. If you want a data section that is read only then you can have that, but if you want a read/write data section that is not executable, sorry, that's not offered.
if there is vocal opposition then surely a majority have heard it?
err.. shouldn't this be under "bugs" and this story, shouldn't it be under well, anything other than bugs? What's going on?
that's right.. god forbid. I want to install it now. I don't want to spend three days doing it. Why is that so hard to comprehend?
oh please. Firstly, the majority of Mac users have heard so much bad news about OS X that they don't want to go near it and secondly, Photoshop users are not the exception, they're the core market!
of course not. But they could give it a good go. Unfortunately they would be stuck on a command line because when the question comes up "What are the vrefresh and vsync rates for your monitor?" they would have no clue. Am I the only one who doesn't immediately scramble for the monitor manual on the first day that I buy a new monitor and write these numbers above the screen? WTF is with that?
shouldn't that be tar.gz + reading the web page / README to determine what other crap you have to have installed before some trivial util you download will work? Most of us who use apt-get and rpm actually have a reason for doing so, because it includes dependancy information.
will you fuck off sphincter breath. I have addressed your stupid comments already.
I installed mojonation on my brother's computer and he asked me what it was. I explained the concept to him and he's like "You mean I could be storing ANYTHING on my computer and I don't know what it is?" and I had to agree. This appears to be the opinion.