If it is documented that way (ie that the WMF file contains a pointer to a function), then I believe you.
However I'm not sure it is documented anywhere what is in a WMF file for SetAbortProc. What I think is that the behavior of the SetAbortProc function *itself* is defined, and they never thought about what would happen if the enumeration they used was imbedded into a WMF file.
Do you have any pointers to contemporary documentation of the SetAbortProc? It would also help to have the same documentation to some function that takes a block of data where it makes sense to put the block into the file (such as "draw this block of text"). This will help to figure out what wording they use to mean things.
No, I am saying the code really is the code you claim is "as_exploit":
AbortProc *fn = (AbortProc *)p;// Points to actual code
What I think is confusing you (and others) is that you are trying to think about how you would write it if you really wanted to make SetAbortProc work at all in a WMF file. I believe however that nobody thought of this at all.
What happened is that there was a function that the WMF interpreter calls:
void do_wmf_record(int code, char* pointer, int length);
And the implemetor of SetAbortProc needed to call this, because internally that function did something they needed. So they implemented SetAbortProc like this:
case AbortProcCode:
AbortProc *fn = (AbortProc *)p;
At no time did anybody think about the fact that if that code was imbedded in a WMF file, the same code would be executed, and with a pointer into the data in the file!
I think we both understand each other. I said earlier that I doubted that anything wrote the SetAbortProc record. As you stated, correctly writing this would require knowing the length of the code to write.
I suspect calling SetAbortProc when writing a WMF file wrote a nonsense length (such as zero) to the file. Somebody needs to test this. This is beacuse the SetAbortProc called the central dispatch routine with a pointer and had to pass a nonsense length, which it knew would be ignored (because they were not thinking about writing a file). I doubt correct use of Microsoft's api could produce a file with an exploit, though it might cause it to crash when read.
However a hand-inserted SetAbortProc enumeration, followed by the code (which the writer knows the length of...) could easily trigger the call. The file reader treats the code as though it was a block of text and puts it in a buffer and passes a pointer, and the length specified by the file, to the dispatch function. The dispatch function then calls the case for SetAbortProc, and that case ignores the length and stores that pointer into AbortProc, thinking it is a pointer shoved through the data interface from an actual call to SetAbortProc. It does not matter how hard it is to cast it and load the segment registers, this code literally has to do all the necessary steps, or SetAbortProc would not work!
I think the confusion we are having is that you are imagining what would be done if somebody literally wanted to save SetAbortProc in a file, perhaps to be played back by the same program, so that a code pointer would still point to some code. In this case, yes, they would write the 4 bytes of pointer to the code to the file. But what you (and the writer of the article) are missing is that nobody intended to write it to a file (even then it certainly was blindingly obvious that it would be a security and stability problem). What we see instead is a side effect of trying to reuse an internal API, not realizing what else is calling that API.
I believe the variable names are an attempt to represent how many bytes were needed to produce that value. Not sure this is a great idea, rather than using a number suffix, but it seems likely this is why those names were chosen.
No-execute does not even stop normal buffer overflows, though it makes them harder. You can still overwrite the return address on the stack, or another pointer to code.
The reason no-execute is useful is the easiest way to get your own code to execute (rather than jumping to some existing code that does something bad) was to write the code itself to the buffer, along with the overflow that causes a pointer to be overwritten so it jumps to the buffer. This will no longer work if the buffer is no-execute.
On modern systems it is quite impossible to print an error (in a gui box) when you run out of memory. everything tries to allocate memory.
PLEASE don't put these checks in. Not everything you learned in COMPSCI-101 is correct. Random checks that people like you insist on putting in are misleading, making anybody reading the code think the zero is a legitimate return value. Directly on malloc it is not confusing, but when that function returns zero and the caller checks, it can mislead somebody maintaining the code into thinking zero is an important and useful value, and they then completely mangle the code trying to "fix" it so that zero works everywhere. I have seen this. Please avoid it! Not everything you learned in compsci-101 is correct.
You are trying to fake exceptions, and there is a reason exceptions have been added to modern languages, because you cannot fake it. Supporting exceptions everywhere may make out-of-memory work. An alternative that is practical right now is to make malloc call some code of your own at the moment it discovers out-of-memory so that you can try to free cached information or gracefully abort. In both of these solutions, malloc never returns zero, so testing is misleading and useless. So again, PLEASE don't do this!
Imagine there is another call to the printer: DrawText(char* buffer, int length). The "buffer" argument is a pointer, pointing at a bunch of characters that should be drawn on the device.
When reading the WMF file, it should be obvious that reading a pointer from the file is useless (it could only print strings that happen to be in the memory space of the program). Instead the actual contents of the buffer are in the WMF file, so it passes a pointer to this data to the function.
The problem is that the same code being used to parse the above hypothetical DrawText call is also able to parse the SetAbortProc call, and it passes an identical pointer, into the file data, to that function.
I think everybody is being confused by the fact that SetAbortProc takes a pointer. This means that if SetAbortProc was purposely put into WMF files, it would make sense to follow it with 4 bytes that are the pointer. The problem is that it was accidentally put into the file, with the result that the executed code is right in there.
The reason the 8086 segment register is set is that they were using "far" pointers and the code dutifully copied the segment into the CS register, thinking it was a legitimate code pointer. If they had stuck to short pointers they would have been forced to pass a pointer to a far pointer and this would not have been as bad of a bug.
The question is why is it still there?
That I agree is a very good question. Microsoft talks a lot about their code reviews but this indicates there are very big holes in them, because I feel the code should have had an obvious flag for pattern-detection of questionable code.
No, I literally mean that it is putting a pointer to the file contents into the AbortProc function pointer.
The problem is that the SetAbortProc function had to shove a pointer to code through some api that was designed to take blocks of data. So they put the code pointer into the data pointer, and had code on the other end cast it back. Then they made a file reader that uses the same api and passes pointers to the file data in the same data pointer, never realizing that one of the possible interpretations is to cast this pointer back to a code pointer.
The version you have would have resulted if the SetAbortProc had instead passed a pointer to the pointer to the code as the argument. That certainly would have worked and made this security hole much harder to exploit, it would also allow them to pass a useful "length" number. But I can certainly see why they did not do that when they were writing this so quickly.
I agree, that's why I said there should have been an obvious cast that they should have automated tools to detect. However I can see how somebody would have typed that cast in originally without realizing it was a backdoor, since it never occurred to them that the code with the cast could be called from a file parser.
Also the code really is in the file, not a pointer. The file parser likely does something like this:
int code = readchar(); int length = readint(); void* pointer = get_pointer_to_next_byte(); advance_file_pointer(length); dispatch_function(code, pointer, length);
Now the mistake was that the implementor of SetAbortProc needed to execute some other useful stuff inside dispatch_function. So instead of SetAbortProc doing this:
AbortProc = pointer;
it was instead implemted like this to get other side effects of dispatch_function:
And added to dispatch_function something like this:
case SetAbortProcCode: AbortProc = (int (*)(hPrinter,int,etc))(pointer); (this is the cast that I think should have been easy to look for)
They never realized that the parser, if it encountered SetAbortProcCode in the file, would call this exact same code with a pointer into the file and thus set AbortProc to point into a buffer. If the AbortProc was called before the buffer was overwritten, code from the file would be executed. It didn't help that 8086 requires no alignment of code, code can be position independent, and there is no way to make a page readable without making it executable.
To further make it work, I'm certain dispatch_function does this as almost the first line:
if (AbortProc(args)) {printer->aborted = true; return;}
Thus the very next record that calls dispatch_function will execute the code for you.
I agree his explanation is a bit off, but I still feel this is a mistake, not something intentional.
Where he is wrong is his assertion that MS saw any reason to put the AbortProc into WMF files. The fact that they work at all is entirely by accident, nobody went and typed in any code that is executed only for making AbortProc run from the file.
What happened is they had an interface of a few hundred calls to print and control printers. They wanted three things: for the calls to work, for the same calls to write a WMF file, and for reading the WMF file to do the same thing as the original calls. The only reliable way to make sure the WMF file does the same thing as the original calls is to make sure they call the same code.
To do this, they made up an enumeration for every call. Every call was then recoded to turn it's arguments into a block of data, a length, and the enumeration value, and to call a central function. This function first checked if a WMF file was being written, in which case the enumeration and block of data was written to a file. Otherwise it ran a big case statement or dispatch table to code that took the arguments back out of the block and implemented the function. When reading a WMF file the reader extracted each enumeration and block and called the function as well. This meant that if the direct call worked, you were almost certain that the write and read of the WMF file worked, too.
It is highly likely this central function did a lot of other code before running the dispatch (such as check if the printer actually exists), and the SetAbortProc needed to do that code as well. So somebody implemented SetAbortProc as another enumeration, and stuck the code pointer into the already-available block pointer, and called the central function. I would guess that they left the block length as garbage (somebody needs to find out if you can write a SetAbortProc call to a WMF file using the normal interface to see. I bet it is not possible to create a usable file this way).
Without any planning they now have the backdoor. If you manually put the enumeration for SetAbortProc into the file, the file-reading code blindly calls the dispatch with that enumeration, a pointer into the file, and a length (which will be ignored). The dispatch calls the interpreter, which sticks the pointer into the AbortProc pointer. I expect the dispatch function also calls the AbortProc as the first thing, so the very next record causes the code to be executed.
Two things about this:
First, the code must have contained an obvious cast to a function pointer from a data pointer. This should have been trivial to catch with automated auditing tools. Once detected, it should have been easy to prove that the normal interface could never write a working SetAbortProc to the stream, so there was no reason to interpret it, and rip the function out of the dispatch and recode SetAbortProc to set the pointer directly.
Second, it is a good reason why such designs are trouble-prone. A stream-based interface is better, where the user code constructs the stream in a buffer, and the contents of this buffer, rather than the calls used to fill it, is the definition of the API. In this design they never would have reused the interface for SetAbortProc.
I think you missed the words "dual license" in my post.
The GPL is useful on your own code if you intend to make money but still want people to see the code. Only you can DUAL LICENSE. Nobody else can. Gives you a huge advantage, and you certainly can use the GPL on your code.
Now I admit that other licenses such as what you propose may give you a bigger advantage, by dual licensing with something somewhat more restrictive than the GPL and thus making your commmercial version more valuable relatively. The main advantages of using the GPL are the name recognition and immediate knowledge by recipients as to what they can and cannot do with the code, and the fact that you can use third-party GPL code in your public version (unfortunately you have to replace this in your closed version, but you can either work on this while the public version is getting known, or you can use your future profits to purchase a non-GPL replacement for that portion).
You need a "license" to copy it because otherwise you are in violation of US and international copyright law. The GPL simply says "hey, I'll let you violate copyright law on my software here if you follow a few rules". If copyright law was repealed, the GPL would be meaningless, since you could copy the software whether or not you adhered to the GPL restrictions.
There is no law that says you cannot use software without permission, so there is no need for a "license" that says you can violate that law, and it is impossible to legally make you unable to use it unless you sign a binding contract saying you agree not to use it. The GPL (and all those EULA's you click "I agree" on) are not binding contracts.
Okay, copyright law says nothing about modification without redistribution.
That paragraph says that you are still in violation of copyright if you distribute a modified version, modifying it is not a way to get around copyright restrictions.
But a modified copy sitting in your own machine means exactly the same as the unmodified copy in your own machine. It does not violate copyright.
The GPL is a license to violate the copyright on the code, if you follow certain rules. Using the code does not violate copyright, so the GPL cannot prevent it.
If you plagarize the NY Times, you may get sued, you may not be able to sell your book. But you are still allowed to read the NY Times.
1. That's why the GPL is largely antithetical to commercial software: every customer can become a competing vendor of your software simply by acquiring one copy from you.
2. I have released a good amount of software under an open-source license, but not the GPL.
You seem to be contradicting yourself. You said that you can't be a commercial vendor of GPL software because anybody can take it and redistribute it. But if that is true, that "competitor" can't be a commercial vendor either! This is because whatever reason you cannot be a commercial vendor also applies to them, they may also have competitors who will rerelease the software.
But you have a huge advantage over your competitors (if you in fact are able to select your license, as you indicate). You really want to use the GPL on the code you send out, because you can dual license. Only you have the right to sell a copy that can be used in closed source. Only you are allowed to sell an enhanced version that has secret extra functions added. Everybody else who gets your software is operating under the "antithetical to commercial software" restriction you stated above. The GPL in this case is 100% to your advantage!
You can of course just distribute your code with no license, so it is covered by copyright. This sounds pretty much like what you are doing, and would in fact give you even more advantage. However in todays world it is unlikely your software will get enough distribution and exposure. The GPL is probably a good compromise.
Yes, if you violated the GPL, your license if void. That is your license to distribute copies! You can still use the GPL software yourself.
Legally, violating copyright means you are liable for monetary damages, and you may be forced to cease and desist distribution of the violating item. However it says nothing about the original item. If you plaguarize the NY Times, they may sue you. However you are still allowed to read the NY Times.
Tripwire is NOT a problem. It is, as you stated, your system. The fact that somebody else cannot run a binary on it is not a problem, just like it is perfectly legal to set a password on your Linux machine so nobody else can log in. If you really want to run that binary, you can turn tripwire off. Because you can circumvent it like this, it is not DRM.
You certainly CAN write DRM software, including software to decode DRM content. Please stop spreading this FUD.
What you cannot do is declare that your DRM software that is using GPL3 code in it is an "effective copyright measure" and thus you cannot declare that breaking it is a DMCA violation. Thus if somebody circumvents it you cannot sue them under the DMCA.
Declaring that it is "not effective" has nothing to do with whether it really is effective. It's just legal mumbo jumbo. In fact a working GPL DRM scheme, probably using hardware-embedded key pairs with a central repository to list "legal" keys (since anybody could make their own new key pair, content producers would use this registry to make sure a key is actually one where the other key is known to be secret), would be very effective.
The above poster has no idea what they are talking about, or is deliberatley spouting bullshit.
First the GPL cannot restrict use. Even if it literally said "movie studios cannot redistribute GPL code", a movie studio could still use Linux all they want. If somebody there fixes the Linux code, they could only use the fix in-house and not give it to anybody, though.
More importantly the GPL3 does not say anything about writing DRM. You can write all the DRM software you want under any license whatsoever. Doing so does not violate the GPL3 copyright (since you are not using that GPL3 code at all). It is impossible for the GPL3 to stop this even if RMS wanted it to, because otherwise the GPL would be a contract instead of a license.
You can even use GPL3 code to write your DRM. All it does is say you cannot claim it is an "effective copyright enforcement". This means that anybody outwitting your DRM cannot be sued under the DMCA, because you are forced to state that your software is not covered by the DMCA. The DMCA and obscurity are the only defenses for DRM code, so it does make it difficult (but not illegal) to write DRM software. If you can actually figure out how to make working GPL DRM code (probably using key pairs with one key embedded in hardware) the result would be almost impossible to break and would probably instantly be the standard for all media. However you would be unable to sue anybody who does break it.
I think you didn't understand. Yes, in fact a working DRM system that used GPL3 code and secret keys would be very effective and almost impossible to break (since it is not relying on obscurity). However if somebody works on breaking it (perhaps by finding a way to make fake key pairs that outwits whatever central registry is used to keep track of legal ones), you cannot sue them under the DMCA. This is because by using GPL3 code in your program you must declare that it is "not an effective copy protection" and thus is not covered by the DMCA. This has nothing to do with wheter it really is effective or not.
No, it would be perfectly legal. What is not legal is claiming that your resulting program is an "effective copyright enforcement" and that breaking any encryption you use is a violation of the DMCA.
You could make an elaborate GPL DRM system (using secret keys sealed in hardware but all algorithims open source) and this is perfectly legal. However if somebody figures out how to break it, you cannot sue them under the DMCA.
Also if you are writing all your own code you can use any license you want, such as modifying the GPL3 by removing the "this is not an effective copyright enforcement" clause.
Slashdot Mirror
If it is documented that way (ie that the WMF file contains a pointer to a function), then I believe you.
However I'm not sure it is documented anywhere what is in a WMF file for SetAbortProc. What I think is that the behavior of the SetAbortProc function *itself* is defined, and they never thought about what would happen if the enumeration they used was imbedded into a WMF file.
Do you have any pointers to contemporary documentation of the SetAbortProc? It would also help to have the same documentation to some function that takes a block of data where it makes sense to put the block into the file (such as "draw this block of text"). This will help to figure out what wording they use to mean things.
No, I am saying the code really is the code you claim is "as_exploit":
// Points to actual code
AbortProc *fn = (AbortProc *)p;
What I think is confusing you (and others) is that you are trying to think about how you would write it if you really wanted to make SetAbortProc work at all in a WMF file. I believe however that nobody thought of this at all.
What happened is that there was a function that the WMF interpreter calls:
void do_wmf_record(int code, char* pointer, int length);
And the implemetor of SetAbortProc needed to call this, because internally that function did something they needed. So they implemented SetAbortProc like this:
void SetAbortProc(AbortProc* p) {
do_wmf_record(AbortProcCode, (void*)p, 0);
}
and then modified do_wmf_record to add this case:
case AbortProcCode:
AbortProc *fn = (AbortProc *)p;
At no time did anybody think about the fact that if that code was imbedded in a WMF file, the same code would be executed, and with a pointer into the data in the file!
I think we both understand each other. I said earlier that I doubted that anything wrote the SetAbortProc record. As you stated, correctly writing this would require knowing the length of the code to write.
I suspect calling SetAbortProc when writing a WMF file wrote a nonsense length (such as zero) to the file. Somebody needs to test this. This is beacuse the SetAbortProc called the central dispatch routine with a pointer and had to pass a nonsense length, which it knew would be ignored (because they were not thinking about writing a file). I doubt correct use of Microsoft's api could produce a file with an exploit, though it might cause it to crash when read.
However a hand-inserted SetAbortProc enumeration, followed by the code (which the writer knows the length of...) could easily trigger the call. The file reader treats the code as though it was a block of text and puts it in a buffer and passes a pointer, and the length specified by the file, to the dispatch function. The dispatch function then calls the case for SetAbortProc, and that case ignores the length and stores that pointer into AbortProc, thinking it is a pointer shoved through the data interface from an actual call to SetAbortProc. It does not matter how hard it is to cast it and load the segment registers, this code literally has to do all the necessary steps, or SetAbortProc would not work!
I think the confusion we are having is that you are imagining what would be done if somebody literally wanted to save SetAbortProc in a file, perhaps to be played back by the same program, so that a code pointer would still point to some code. In this case, yes, they would write the 4 bytes of pointer to the code to the file. But what you (and the writer of the article) are missing is that nobody intended to write it to a file (even then it certainly was blindingly obvious that it would be a security and stability problem). What we see instead is a side effect of trying to reuse an internal API, not realizing what else is calling that API.
Just to repeat what a mod-0 comment says:
It's "World out of Time" by Larry Niven. Also there was a short story called "Rammer" which is the first chapter of the book.
I believe the variable names are an attempt to represent how many bytes were needed to produce that value. Not sure this is a great idea, rather than using a number suffix, but it seems likely this is why those names were chosen.
No-execute does not even stop normal buffer overflows, though it makes them harder. You can still overwrite the return address on the stack, or another pointer to code.
The reason no-execute is useful is the easiest way to get your own code to execute (rather than jumping to some existing code that does something bad) was to write the code itself to the buffer, along with the overflow that causes a pointer to be overwritten so it jumps to the buffer. This will no longer work if the buffer is no-execute.
On modern systems it is quite impossible to print an error (in a gui box) when you run out of memory. everything tries to allocate memory.
PLEASE don't put these checks in. Not everything you learned in COMPSCI-101 is correct. Random checks that people like you insist on putting in are misleading, making anybody reading the code think the zero is a legitimate return value. Directly on malloc it is not confusing, but when that function returns zero and the caller checks, it can mislead somebody maintaining the code into thinking zero is an important and useful value, and they then completely mangle the code trying to "fix" it so that zero works everywhere. I have seen this. Please avoid it! Not everything you learned in compsci-101 is correct.
You are trying to fake exceptions, and there is a reason exceptions have been added to modern languages, because you cannot fake it. Supporting exceptions everywhere may make out-of-memory work. An alternative that is practical right now is to make malloc call some code of your own at the moment it discovers out-of-memory so that you can try to free cached information or gracefully abort. In both of these solutions, malloc never returns zero, so testing is misleading and useless. So again, PLEASE don't do this!
I think I'm not explaining this clearly.
Imagine there is another call to the printer: DrawText(char* buffer, int length). The "buffer" argument is a pointer, pointing at a bunch of characters that should be drawn on the device.
When reading the WMF file, it should be obvious that reading a pointer from the file is useless (it could only print strings that happen to be in the memory space of the program). Instead the actual contents of the buffer are in the WMF file, so it passes a pointer to this data to the function.
The problem is that the same code being used to parse the above hypothetical DrawText call is also able to parse the SetAbortProc call, and it passes an identical pointer, into the file data, to that function.
I think everybody is being confused by the fact that SetAbortProc takes a pointer. This means that if SetAbortProc was purposely put into WMF files, it would make sense to follow it with 4 bytes that are the pointer. The problem is that it was accidentally put into the file, with the result that the executed code is right in there.
The reason the 8086 segment register is set is that they were using "far" pointers and the code dutifully copied the segment into the CS register, thinking it was a legitimate code pointer. If they had stuck to short pointers they would have been forced to pass a pointer to a far pointer and this would not have been as bad of a bug.
The question is why is it still there?
That I agree is a very good question. Microsoft talks a lot about their code reviews but this indicates there are very big holes in them, because I feel the code should have had an obvious flag for pattern-detection of questionable code.
No, I literally mean that it is putting a pointer to the file contents into the AbortProc function pointer.
The problem is that the SetAbortProc function had to shove a pointer to code through some api that was designed to take blocks of data. So they put the code pointer into the data pointer, and had code on the other end cast it back. Then they made a file reader that uses the same api and passes pointers to the file data in the same data pointer, never realizing that one of the possible interpretations is to cast this pointer back to a code pointer.
The version you have would have resulted if the SetAbortProc had instead passed a pointer to the pointer to the code as the argument. That certainly would have worked and made this security hole much harder to exploit, it would also allow them to pass a useful "length" number. But I can certainly see why they did not do that when they were writing this so quickly.
I agree, that's why I said there should have been an obvious cast that they should have automated tools to detect. However I can see how somebody would have typed that cast in originally without realizing it was a backdoor, since it never occurred to them that the code with the cast could be called from a file parser.
Also the code really is in the file, not a pointer. The file parser likely does something like this:
int code = readchar();
int length = readint();
void* pointer = get_pointer_to_next_byte();
advance_file_pointer(length);
dispatch_function(code, pointer, length);
Now the mistake was that the implementor of SetAbortProc needed to execute some other useful stuff inside dispatch_function. So instead of SetAbortProc doing this:
AbortProc = pointer;
it was instead implemted like this to get other side effects of dispatch_function:
dispatch_function(SetAbortProcCode, (void*)function, 0);
And added to dispatch_function something like this:
case SetAbortProcCode:
AbortProc = (int (*)(hPrinter,int,etc))(pointer);
(this is the cast that I think should have been easy to look for)
They never realized that the parser, if it encountered SetAbortProcCode in the file, would call this exact same code with a pointer into the file and thus set AbortProc to point into a buffer. If the AbortProc was called before the buffer was overwritten, code from the file would be executed. It didn't help that 8086 requires no alignment of code, code can be position independent, and there is no way to make a page readable without making it executable.
To further make it work, I'm certain dispatch_function does this as almost the first line:
if (AbortProc(args)) {printer->aborted = true; return;}
Thus the very next record that calls dispatch_function will execute the code for you.
I agree his explanation is a bit off, but I still feel this is a mistake, not something intentional.
Where he is wrong is his assertion that MS saw any reason to put the AbortProc into WMF files. The fact that they work at all is entirely by accident, nobody went and typed in any code that is executed only for making AbortProc run from the file.
What happened is they had an interface of a few hundred calls to print and control printers. They wanted three things: for the calls to work, for the same calls to write a WMF file, and for reading the WMF file to do the same thing as the original calls. The only reliable way to make sure the WMF file does the same thing as the original calls is to make sure they call the same code.
To do this, they made up an enumeration for every call. Every call was then recoded to turn it's arguments into a block of data, a length, and the enumeration value, and to call a central function. This function first checked if a WMF file was being written, in which case the enumeration and block of data was written to a file. Otherwise it ran a big case statement or dispatch table to code that took the arguments back out of the block and implemented the function. When reading a WMF file the reader extracted each enumeration and block and called the function as well. This meant that if the direct call worked, you were almost certain that the write and read of the WMF file worked, too.
It is highly likely this central function did a lot of other code before running the dispatch (such as check if the printer actually exists), and the SetAbortProc needed to do that code as well. So somebody implemented SetAbortProc as another enumeration, and stuck the code pointer into the already-available block pointer, and called the central function. I would guess that they left the block length as garbage (somebody needs to find out if you can write a SetAbortProc call to a WMF file using the normal interface to see. I bet it is not possible to create a usable file this way).
Without any planning they now have the backdoor. If you manually put the enumeration for SetAbortProc into the file, the file-reading code blindly calls the dispatch with that enumeration, a pointer into the file, and a length (which will be ignored). The dispatch calls the interpreter, which sticks the pointer into the AbortProc pointer. I expect the dispatch function also calls the AbortProc as the first thing, so the very next record causes the code to be executed.
Two things about this:
First, the code must have contained an obvious cast to a function pointer from a data pointer. This should have been trivial to catch with automated auditing tools. Once detected, it should have been easy to prove that the normal interface could never write a working SetAbortProc to the stream, so there was no reason to interpret it, and rip the function out of the dispatch and recode SetAbortProc to set the pointer directly.
Second, it is a good reason why such designs are trouble-prone. A stream-based interface is better, where the user code constructs the stream in a buffer, and the contents of this buffer, rather than the calls used to fill it, is the definition of the API. In this design they never would have reused the interface for SetAbortProc.
I think you missed the words "dual license" in my post.
The GPL is useful on your own code if you intend to make money but still want people to see the code. Only you can DUAL LICENSE. Nobody else can. Gives you a huge advantage, and you certainly can use the GPL on your code.
Now I admit that other licenses such as what you propose may give you a bigger advantage, by dual licensing with something somewhat more restrictive than the GPL and thus making your commmercial version more valuable relatively. The main advantages of using the GPL are the name recognition and immediate knowledge by recipients as to what they can and cannot do with the code, and the fact that you can use third-party GPL code in your public version (unfortunately you have to replace this in your closed version, but you can either work on this while the public version is getting known, or you can use your future profits to purchase a non-GPL replacement for that portion).
You have really bought into the FUD, haven't you.
You do not need a "license" to use software!
You need a "license" to copy it because otherwise you are in violation of US and international copyright law. The GPL simply says "hey, I'll let you violate copyright law on my software here if you follow a few rules". If copyright law was repealed, the GPL would be meaningless, since you could copy the software whether or not you adhered to the GPL restrictions.
There is no law that says you cannot use software without permission, so there is no need for a "license" that says you can violate that law, and it is impossible to legally make you unable to use it unless you sign a binding contract saying you agree not to use it. The GPL (and all those EULA's you click "I agree" on) are not binding contracts.
Okay, copyright law says nothing about modification without redistribution.
That paragraph says that you are still in violation of copyright if you distribute a modified version, modifying it is not a way to get around copyright restrictions.
But a modified copy sitting in your own machine means exactly the same as the unmodified copy in your own machine. It does not violate copyright.
The GPL is a license to violate the copyright on the code, if you follow certain rules. Using the code does not violate copyright, so the GPL cannot prevent it.
If you plagarize the NY Times, you may get sued, you may not be able to sell your book. But you are still allowed to read the NY Times.
1. That's why the GPL is largely antithetical to commercial software: every customer can become a competing vendor of your software simply by acquiring one copy from you.
2. I have released a good amount of software under an open-source license, but not the GPL.
You seem to be contradicting yourself. You said that you can't be a commercial vendor of GPL software because anybody can take it and redistribute it. But if that is true, that "competitor" can't be a commercial vendor either! This is because whatever reason you cannot be a commercial vendor also applies to them, they may also have competitors who will rerelease the software.
But you have a huge advantage over your competitors (if you in fact are able to select your license, as you indicate). You really want to use the GPL on the code you send out, because you can dual license. Only you have the right to sell a copy that can be used in closed source. Only you are allowed to sell an enhanced version that has secret extra functions added. Everybody else who gets your software is operating under the "antithetical to commercial software" restriction you stated above. The GPL in this case is 100% to your advantage!
You can of course just distribute your code with no license, so it is covered by copyright. This sounds pretty much like what you are doing, and would in fact give you even more advantage. However in todays world it is unlikely your software will get enough distribution and exposure. The GPL is probably a good compromise.
Yes, if you violated the GPL, your license if void. That is your license to distribute copies! You can still use the GPL software yourself.
Legally, violating copyright means you are liable for monetary damages, and you may be forced to cease and desist distribution of the violating item. However it says nothing about the original item. If you plaguarize the NY Times, they may sue you. However you are still allowed to read the NY Times.
Copyright law says nothing about modification. It does not prevent it, and therefore the GPL does not, either. Go ahead and modify all you want.
Tripwire is NOT a problem. It is, as you stated, your system. The fact that somebody else cannot run a binary on it is not a problem, just like it is perfectly legal to set a password on your Linux machine so nobody else can log in. If you really want to run that binary, you can turn tripwire off. Because you can circumvent it like this, it is not DRM.
You certainly CAN write DRM software, including software to decode DRM content. Please stop spreading this FUD.
What you cannot do is declare that your DRM software that is using GPL3 code in it is an "effective copyright measure" and thus you cannot declare that breaking it is a DMCA violation. Thus if somebody circumvents it you cannot sue them under the DMCA.
Declaring that it is "not effective" has nothing to do with whether it really is effective. It's just legal mumbo jumbo. In fact a working GPL DRM scheme, probably using hardware-embedded key pairs with a central repository to list "legal" keys (since anybody could make their own new key pair, content producers would use this registry to make sure a key is actually one where the other key is known to be secret), would be very effective.
The above poster either has no idea what they are talking about, or is spreading FUD.
There is no such clause or anything like it in the GPL3.
Even if there was, it could not prevent use of Linux, it could only prevent the company from modifying Linux and selling/distributing it to others.
The above poster has no idea what they are talking about, or is deliberatley spouting bullshit.
First the GPL cannot restrict use. Even if it literally said "movie studios cannot redistribute GPL code", a movie studio could still use Linux all they want. If somebody there fixes the Linux code, they could only use the fix in-house and not give it to anybody, though.
More importantly the GPL3 does not say anything about writing DRM. You can write all the DRM software you want under any license whatsoever. Doing so does not violate the GPL3 copyright (since you are not using that GPL3 code at all). It is impossible for the GPL3 to stop this even if RMS wanted it to, because otherwise the GPL would be a contract instead of a license.
You can even use GPL3 code to write your DRM. All it does is say you cannot claim it is an "effective copyright enforcement". This means that anybody outwitting your DRM cannot be sued under the DMCA, because you are forced to state that your software is not covered by the DMCA. The DMCA and obscurity are the only defenses for DRM code, so it does make it difficult (but not illegal) to write DRM software. If you can actually figure out how to make working GPL DRM code (probably using key pairs with one key embedded in hardware) the result would be almost impossible to break and would probably instantly be the standard for all media. However you would be unable to sue anybody who does break it.
Apparently you are unaware that there is a program called "chmod".
The answer is actually NO. Protection on files is not DRM.
I think you didn't understand. Yes, in fact a working DRM system that used GPL3 code and secret keys would be very effective and almost impossible to break (since it is not relying on obscurity). However if somebody works on breaking it (perhaps by finding a way to make fake key pairs that outwits whatever central registry is used to keep track of legal ones), you cannot sue them under the DMCA. This is because by using GPL3 code in your program you must declare that it is "not an effective copy protection" and thus is not covered by the DMCA. This has nothing to do with wheter it really is effective or not.
No, it would be perfectly legal. What is not legal is claiming that your resulting program is an "effective copyright enforcement" and that breaking any encryption you use is a violation of the DMCA.
You could make an elaborate GPL DRM system (using secret keys sealed in hardware but all algorithims open source) and this is perfectly legal. However if somebody figures out how to break it, you cannot sue them under the DMCA.
Also if you are writing all your own code you can use any license you want, such as modifying the GPL3 by removing the "this is not an effective copyright enforcement" clause.