While it is true that some multi-media content is a PITA on Linux, this is hardly the fault of open source but more a symptom of a lack of usable standards in the industry.
I have been using Linux exclusively as my desktop, and when I have to use Windows I feel I am in a prison cell. Things that are easy in Linux are painfully difficult in Windows, and things that are easy in Windows, can often be difficult on Linux.
However, articles never focus on the difficulties of Windows, only the problems with the easy things on Windows being difficult on Linux. Why not take all the time users spend updating McAffee and other anti-virus software and learn Linux? Why not take the time users have to reboot, and learn Linux. And so on.
You can't build a house on sand. Apply the 80/20 rule, 80% of the drivers could be supported by a standardized kernel API.
I/O, Memory, interrupts, DMA, device slots, and etc. are not rocket science. Most devices would benefit from a standardized API, be it done in macros or function call-outs.
Personally, I don't thing a pure binary API is a good idea, but a mix of macros, structures, functions, and a bit of abstraction would make a HUGE impact on driver development and maintenence.
If you read carefully and verify this yourself, it is not untrue. It may cause FUD about Windows, but unlike Microsoft's "Get The Facts" nonsense, this FUD is justified.
FUD -- Fear, Uncertainty, and Doubt, like paranoia, is sometimes the correct response to the facts. Like Kissinger said, "Just because you're paranoid, doesn't mean they're not out to get you." In this case, just because it causes FUD, doesn't mean its a lie.
OK, here's the difference between Windows (DOS and NT) coding and UNIX coding, and you may feel free to check out the various Windows DDK examples and the Linux drivers to verify.
In UNIX a driver does not nuke the system unless there are no alternatives, and a great deal of effort is made to make sure this doesn't happen. In Windows land all the DDK examples in both DOS Windows and NT, upon encountering a problem, they are encouraged to issue a stop. (similar to a kernel panic) rather than fail to operate.
This means that a printer driver, in kernel space, will kill a system rather than fail to print. So, with Windows, you will lose work, with Linux, you will be able to save your work.
This isn't to say Linux is perfect, it does have bugs, all software does, but it has fewer and is more tollerant of them.
OK, nice strawman. Yes, you are right, it has to change yada yada yada.
At issue is the frequency of change. Think about the C file I/O API. It has not changed in almost 30 years. Why not? Because it didn't need too. It was designed up front. Everything under it changed, of course, but it didn't.
It is not impossible to standardize certain APIs and continue to grow. That's the point of an API it is an "interface," not an "implementation. "
I have read this piece before, and while I think it is very good, it and I both agree that a "binary interface" is a bad idea. I am not suggesting that at all. I am suggesting that, as part of the kernel, define a stable API.
Look at the current APIs, augment or "bless them." Don't access structures, use macros. Bless tried and true interfaces, and make damn sure no one changes them without keeping backward compatibility. Assign temporary status to "experimental" interfaces.
Maybe create a synthetic API layer analogous to Windows NDIS sort of thing, where common peripherals can just code to that and be done. That way, the vast majority of simple devices will just come along for the ride.
There are lots of steps that can be taken. At issue is a fact of life people ignore: The strategies and skills used to attain success, are not the same as those needed to maintain and continue succeeding.
To use a marathon metaphor, Linux is no longer sprinting to catch up, we are in the game. As such, we need to recognze and understand we can't sprint forever, we need to settle down and pace ourselves, this is a long race, and the winner will be the one that plans ahead.
When the Linux kernel was small, changes could be made to the whole source tree easily. As it gets larger and larger, one obscure change in one section of the kernel may not generate an error or even a warning, but may break a driver you didn't even know about. That is exactly what we are seeing.
Oh please, this is total BS. The only way you could have a dozen or more panics in a year is if you have a VERY BAD device and driver and have not looked at addressing the problem.
I've been running Linux since 1994, and exclusively since 1996. I have seen two panics, having to do with an old 3Com card and an old Promise IDE driver.
When you get any sort of prolem, in Linux, Mac, or what ever, you look for the updated driver and get it, or if there isn't one, troubleshoot the system. Unlike Windows, crashing on UNIX is not normal, and a sign of a problem that won't go away on a reboot.
For the record, I have a couple servers using 2.6.x that have been up for almost a year with no issues. The last reboot was because of a power failure at the colo.
I have been using Linux since the early 1990's and I've been a software developer for almost 30 years. The one ting that concerns me, and I think this recent indictment is just a symptom of a larger problem.
The problem is that the drivers have to remain in constant flux because the kernel API is always changing. Now, when there are a limited number of drivers, this means that you can move quickly on the kernel. As you add more and more drivers, you add more and more work to keep the drivers updated. Eventually, there is more work needed to update the drivers than modify the kernel, and the drivers become your sticking point.
This is where I believe Linux is stuck. Linus and the kernel team has to look at the various kernel APIs and standardize them with the next release.
Sorry guys, time to grow up. Linux *is* mainstream!
Seriously, this debate is so early 1990s.
I've been developing software for close to 30 years, including a lot of embedded software and kernel drivers. The Microkernel debate is interesting, and the ideals it proposes are also good.
The problem with Microkernels is that it puts up artificial barriers to functionality. It doesn't merely try to wrap functionality in a neat and clean and easy to use API. It attempts to force your development into an abstract model that has little to actually do with the way real computers work.
Because of this, the slope is sufficiently steep and slippery for those "exceptions" to creep in quickly. This is, in fact, what happend to Windows NT. When it was first released, NT 3.1 was an attempt at a microkernel, but not only was it slow, but the mechanisms to manage shared subsystems were at best complex. Soon, people were working around the microkernel. By NT 4.0, the microkernel approach had been abandoned.
This brings up a second point, a Microkernel depends on people coding to spec, which they will abandon quickly if the microkernel gets in the way.
Andrew T is a great CompSi teacher, I'm sure, but as for practical matters, I think a clean modular kernel, while theoretically less reliable, in pactice show to be just as reliable. The think that kills most systems, Windows not included, is device driver failures, I don't care what you think, a Microkernel still has to access hardware, and as long as hardware is not perfect, the software that interfaces to it can not be either.
While Dvorak is usually an idiot and right for all the wrong reasons, or flat out wrong, there is an amount of truth in his analysis of IE.
Lacking, of course, is consideration for its purpose of destroying Netscape to preserve the MS Monopoly. Also, while he stands in 2006 and says that "intenet appliances" never happened, he neglects the role IE played in destroying web standards and making appliances practically impossible.
The thinking being that the Microsoft monopoly platforms would have to run what ever appliance applications were available, with IE, Microsoft was able to keep the APIs and systems subtally different from public APIs. While you could have coded internet appliance applications, it was very difficult. The IE version-o-matic of the late 90s kept *any* interesting content not based on ActiveX out of the mainstream.
So, in the end, the amazing MSnovation to prohibit actual "innovation" worked again.
But, yes, looking over the past 5 or 6 years, Microsoft injured computer innovation with IE, but could not kill it. The browser wars are back, and it is likely that Microsoft can't play the same game twice.
What a looser. Linux was gaining popularity before Oracle ran on it. Yes, a lot of open source projects have benefited by corporate investment, but they were there and gaining popularity before corporate investment. Big corporations benefit from open source, by adding resources, they have benefitted even more.
Just because they give money, doesn't mean that they run the party. What's the difference between god and Larry Ellison? God doesn't think he's Larry Ellison.
Sigh, yes, that *is* the way it is documented. If you would have only google'd for this information before you this exchange it could have saved a lot of time. What I saw as a misunderstanding was in fact merely someone not even educating themselves about the basics of the discussion. The Windows metafile format is old, really old, and there is lots of info available. Try google, it helps.
Secondly, the fact still remains that you are totally confused about pointers. A function pointer holds an address of a function. A data pointer points to the location of data. There is an inherent indirection in a function pointer and it could not possibly be used in the same way for both a function pointer and the address of an actual function. Maybe you are not a C/C++ guy, but merely casting different pointer types does not invoke any extra functionality, It just tells the compiler how you want to use the value. You easily shoot yourself in the foot if you are even the least bit fuzzy about pointers. That's why the two different modes don't work. The compiler won't fix it for you and you'll crash.
This is silly, as the API is documented, the metafile contains an address. Period. This true and this is how it is documented and this is how it works. There is no way that code, that is implemeted as documented, that reads 4 bytes out of a file, or memory buffer, or whatever, *can* confuse the indirection of a pointer in the way you keep insisting. I have been developing software using C or C++ for about 20 years now and I kind of know what I'm talking about.
In the simplest terms, the metafile AbortProc tag data is an AbortProc *p, NOT an AbortProc p. One way works, one way simply does not. Just because you seem to be very confused about pointer indirection does not mean that the compiler would be as well.
It is impossible to create one path of code that does both with the same execution strategy.
If you disagree, try this: #include void foo() {
printf("It worked\n"); } typedef void (*myfn)(void); char buffer[4096]; int main() {
myfn bar = foo;
(*bar)();
bar = (myfn) buffer;
memcpy(bar, foo, 200);// 200 bytes should be enough
(*bar)(); }
Again, you seem to be confused about how C/C++ pointers work. You are confusing a "pointer" with a "pointer to a pointer" CODE: int len = get_file_length(wmf); void *wmfbuf = read_file(wmf, len); int pos=0; while(1) { TAG *tag;// Will contain tag info
void *p = get_next_record(wmfbuf, &tag, &pos);// Void pointer P points to the data supplied in the file
switch(tag.type)
{ case SET_ABORT_PROC:{
if(as_documented){
AbortProc ** pfn = (AbortProc **)p;// P Points to address of function
AbortProc * fn = *pfn;// Copies 4 byte address from pfn into fn;
}
else if(as_exploit){
AbortProc *fn = (AbortProc *)p;// Points to actual code
}
break;
}
} In the above example, the pointer (fn) is initialized with the first four bytes of data from where pfn points. Your argument implies that the compiler will confuse a "AbortProc *fn" and "AbortProc **pfn" which would cause an error.
This is basic C/C++ pointer stuff and I assure you, there are different types of pointers and it is not possible to confuse the two and still have both work. Each behavior MUST be coded separately.
No, you are explaining what you are saying perfectly, it is just that you are incorrect. There is no way that code would "accidentally" be put into the file. It would always be just the 4 byte function pointer.
The difference between a call like "DrawText" and "SetAbortProc" is that code is unlike data. Data has some delimiting quality, like a count of bytes or a zero termination. To copy executable code into file would require additional information, starting point (probably the pointer) and count of bytes to copy, which is not present in SetAbortProc, I doubt it is possible to even extract this information in C without some real ugliness.
When I talked about DS to CS aliasing I was talking about protected 16 bit mode of the 80286 and 80386. In real mode Windows you could not make an arbitrary far call (32 bit) as Windows moved and delete code segments that were not in use. You needed to make a far call into a thunk which would ensure that your code segment was in memory.
You're not getting it!! In C "casting" doesn't do magic. In the most basic terms, the correct implementation, you read four bytes from the metafile, and that points to the address of your AbortProc in the system. That is *THE* *DOCUMENTED* behavior of the function.
The exploit implementation is where the code is executed, it is a strange API, it loads the file into RAM and then jumps blindly into the block of code loaded from the file, it is sloppy and dangerous, but *this* is the exploit that is problematic and being discussed.
In fact, in Win16 days, you would have to REALLY go out of your way to do this because have to make a DS to CS alias to allow executon on that segment of memory. (In 80286 potected mode data segment selectors did not allow execution, you had to create a "code segment" to execute it)
The exploit implementation is VERY difficult to maintain over OS, compiler, and language changes for a couple decades. It is not by accident that this function is still there. The question is why is it still there?
You are sort of missing the point, when used as documented, the SetAbortProc contains a pointer to a function. When used as the exploit, it executes the code embedded in the file. There are two distict methods of executing code and can not be handled by the same chunk of code.
You gave this as an exmaple:
int code = readchar(); int length = readint(); void* pointer = get_pointer_to_next_byte(); advance_file_pointer(length); dispatch_function(code, pointer, length);
The problem is that there seems to be a misunderstanding of pointers in C here.
AbortProc *fn;
read(&fn, sizeof(AbortProc), file);
IS NOT THE SAME AS:
read(pointer, file_size, file); fn = pointer;
In the first example we are reading sizeof(AbortProc) bytes from the file into the function pointer, which then points to a location in memory as descrived by the data read. In the second example, we are setting the function pointer to the location of memory into which the contents of the file was read.
The problem wth your post is that you state that there is no difference between executing code in a file vs executing a function address. This is incorrect. It is IMPOSSIBLE for code designed to read a pointer out of a file or memory address and call that address to jump to the locaton of what should be a pointer.
These two distinct behaviors must be coded differently and must be maintined differently as compilers, bit depths, and core OS change over time.
I still say the the embedded code aspect of the metafile is damning and unexplained. Waived away, easily, as "lost with the origial programmer," but completely ignoring the almost two decades that the code has been maintained and working.
His technical abilities are solid and his access to NT source is no doubt a great advantage. That being said, writing technical articles is one thing, but he never takes the step to examine *why* microsoft has done something nor does he bring to light any insight about motivations.
In his blog, he dismisses the reason for one of the most damning aspects of the metafile exploit as lost with the original programmer. Ignoring that long since the original developer, the code has to have been maintained, and if maintained, tested, on a progressive line of Windows changes over the years.
If there was no known reason for the code, it is inherently hard to test, it would have been removed had there been no use for it.
While Steve Gibson is a bit of a crank, Mark Russinovich is also a Microsoft Apologist. Here are my problems with the explaination:
Reading an address:
SetAbortProc * fn;
read(&fn, sizeof(SetAbortProc), wmf);
(fn)(...)
vs
Reading code:
read(code, bytecount, wmf)
SetAbortProc * fn;
fn = (SetAbortProc) code;
(fn)(...);
Even Mark was a little confused about this behavior:
"The remaining question is why PlayMetaFile expects the abort procedure to
be in-lined in the metafile. It's that fact that allows a hacker to
transport malicious code within a WMF file. The actual reason is lost with
the original developer of the API"
He then goes on to make an excuse for the developer being flexable or
something. NO developer would see the utility of embedding code in
Windows 3.1 or even Win32 as the code fixups are not made in a data source.
In Win16 days, you wouldn't have access to your data segment. If this bug
was around in real mode days, you couldn't even be sure your program was in
memory without a thunk.
It is this feature that is the dangerous and of the most dubious utility,
and it is this feature that gets a quickest glossing over. I am reminded of
the NSA key BS about Microsoft needing a duplicate key in case they lost
the original. Give me a break.
Now, I respect Mark Russinovich's technical abilities, but he has, most of
the time, been a Microsoft apologist, and I don't think that this piece is
any different. There is a feature that allows arbitrary code to be
executed, there is no real reason for it being there as developing code to
use it would require a different tool chain than that used to create
applications. As the Windows API went from 16 bit to 32 bit, from a DOS
extender to a VMS hack, this functionality has been maintained, and that
would require work as the C language and compilers and bit depths have
changed over the years.
Sorry, I don't trust Microsoft, if its there and has been maintained for
some time, it is there for a reason. What is that reason?
You'd be surprised what a little noteriety would do for some of the troglodyte Linux hackers.
(FWIW: I am a hacker, but I have no interest in security. Give me a good parallel processing problem, and I'm all over it.)
You say that Microsoft is sitting on a treasure chest 10 years of "bugfixed, known-to-be-working" code.
As a former Windows developer, since version 1.03, and who was a Windows NT kernel developer since NT 3.1 (The first version), I can say I hear what you are saying, but "bugfixed, and known-to-be-working" code is only valuable if it can be said that the foundation of the code is solid.
If the foundation of the code is bad, its like putting fresh paint on a house with termites and wood-rot.
The core of NT was good when Cutler first worked on it. Since then, Microsoft has compromised every aspect of NT that was good. That valuable "bugfixed" code is mostly code that was in error in the first place.
The general design of Win32 (and Win16 prior) is too reliant on little or no security between applications. As long as there is a need for normal users to have "Administrator" rights for their applications to run or install correctly, Windows will always be a disaster.
These debates are as silly as they are pointless. Stored procedures are an important tool within a SQL database. They are part of the SQL standard and should be there. Trying to say they are good or bad is like asking if a socket wrench is good or bad.
There is a lot of overlap between what can be done in a "business logic" language, like Java or VB, and what can be done in a SQL stored procedure. Like all "gray area" arguments, the simple problems are a matter of choice as to where you want to solve them and which method is easiest. In the "real world" "real problems" often dictate where they must get solved.
When you need a stored procedure, it sucks not to have them. That is why I NEVER use MySQL.
Slashdot Mirror
While it is true that some multi-media content is a PITA on Linux, this is hardly the fault of open source but more a symptom of a lack of usable standards in the industry.
I have been using Linux exclusively as my desktop, and when I have to use Windows I feel I am in a prison cell. Things that are easy in Linux are painfully difficult in Windows, and things that are easy in Windows, can often be difficult on Linux.
However, articles never focus on the difficulties of Windows, only the problems with the easy things on Windows being difficult on Linux. Why not take all the time users spend updating McAffee and other anti-virus software and learn Linux? Why not take the time users have to reboot, and learn Linux. And so on.
You can't build a house on sand. Apply the 80/20 rule, 80% of the drivers could be supported by a standardized kernel API.
I/O, Memory, interrupts, DMA, device slots, and etc. are not rocket science. Most devices would benefit from a standardized API, be it done in macros or function call-outs.
Personally, I don't thing a pure binary API is a good idea, but a mix of macros, structures, functions, and a bit of abstraction would make a HUGE impact on driver development and maintenence.
If you read carefully and verify this yourself, it is not untrue. It may cause FUD about Windows, but unlike Microsoft's "Get The Facts" nonsense, this FUD is justified.
FUD -- Fear, Uncertainty, and Doubt, like paranoia, is sometimes the correct response to the facts. Like Kissinger said, "Just because you're paranoid, doesn't mean they're not out to get you." In this case, just because it causes FUD, doesn't mean its a lie.
OK, here's the difference between Windows (DOS and NT) coding and UNIX coding, and you may feel free to check out the various Windows DDK examples and the Linux drivers to verify.
In UNIX a driver does not nuke the system unless there are no alternatives, and a great deal of effort is made to make sure this doesn't happen. In Windows land all the DDK examples in both DOS Windows and NT, upon encountering a problem, they are encouraged to issue a stop. (similar to a kernel panic) rather than fail to operate.
This means that a printer driver, in kernel space, will kill a system rather than fail to print. So, with Windows, you will lose work, with Linux, you will be able to save your work.
This isn't to say Linux is perfect, it does have bugs, all software does, but it has fewer and is more tollerant of them.
OK, nice strawman. Yes, you are right, it has to change yada yada yada.
At issue is the frequency of change. Think about the C file I/O API. It has not changed in almost 30 years. Why not? Because it didn't need too. It was designed up front. Everything under it changed, of course, but it didn't.
It is not impossible to standardize certain APIs and continue to grow. That's the point of an API it is an "interface," not an "implementation. "
I have read this piece before, and while I think it is very good, it and I both agree that a "binary interface" is a bad idea. I am not suggesting that at all. I am suggesting that, as part of the kernel, define a stable API.
Look at the current APIs, augment or "bless them."
Don't access structures, use macros.
Bless tried and true interfaces, and make damn sure no one changes them without keeping backward compatibility.
Assign temporary status to "experimental" interfaces.
Maybe create a synthetic API layer analogous to Windows NDIS sort of thing, where common peripherals can just code to that and be done. That way, the vast majority of simple devices will just come along for the ride.
There are lots of steps that can be taken. At issue is a fact of life people ignore: The strategies and skills used to attain success, are not the same as those needed to maintain and continue succeeding.
To use a marathon metaphor, Linux is no longer sprinting to catch up, we are in the game. As such, we need to recognze and understand we can't sprint forever, we need to settle down and pace ourselves, this is a long race, and the winner will be the one that plans ahead.
When the Linux kernel was small, changes could be made to the whole source tree easily. As it gets larger and larger, one obscure change in one section of the kernel may not generate an error or even a warning, but may break a driver you didn't even know about. That is exactly what we are seeing.
Linux is no longer a small and simple kernel.
Oh please, this is total BS. The only way you could have a dozen or more panics in a year is if you have a VERY BAD device and driver and have not looked at addressing the problem.
I've been running Linux since 1994, and exclusively since 1996. I have seen two panics, having to do with an old 3Com card and an old Promise IDE driver.
When you get any sort of prolem, in Linux, Mac, or what ever, you look for the updated driver and get it, or if there isn't one, troubleshoot the system. Unlike Windows, crashing on UNIX is not normal, and a sign of a problem that won't go away on a reboot.
For the record, I have a couple servers using 2.6.x that have been up for almost a year with no issues. The last reboot was because of a power failure at the colo.
I have been using Linux since the early 1990's and I've been a software developer for almost 30 years. The one ting that concerns me, and I think this recent indictment is just a symptom of a larger problem.
The problem is that the drivers have to remain in constant flux because the kernel API is always changing. Now, when there are a limited number of drivers, this means that you can move quickly on the kernel. As you add more and more drivers, you add more and more work to keep the drivers updated. Eventually, there is more work needed to update the drivers than modify the kernel, and the drivers become your sticking point.
This is where I believe Linux is stuck. Linus and the kernel team has to look at the various kernel APIs and standardize them with the next release.
Sorry guys, time to grow up. Linux *is* mainstream!
Seriously, this debate is so early 1990s. I've been developing software for close to 30 years, including a lot of embedded software and kernel drivers. The Microkernel debate is interesting, and the ideals it proposes are also good. The problem with Microkernels is that it puts up artificial barriers to functionality. It doesn't merely try to wrap functionality in a neat and clean and easy to use API. It attempts to force your development into an abstract model that has little to actually do with the way real computers work. Because of this, the slope is sufficiently steep and slippery for those "exceptions" to creep in quickly. This is, in fact, what happend to Windows NT. When it was first released, NT 3.1 was an attempt at a microkernel, but not only was it slow, but the mechanisms to manage shared subsystems were at best complex. Soon, people were working around the microkernel. By NT 4.0, the microkernel approach had been abandoned. This brings up a second point, a Microkernel depends on people coding to spec, which they will abandon quickly if the microkernel gets in the way. Andrew T is a great CompSi teacher, I'm sure, but as for practical matters, I think a clean modular kernel, while theoretically less reliable, in pactice show to be just as reliable. The think that kills most systems, Windows not included, is device driver failures, I don't care what you think, a Microkernel still has to access hardware, and as long as hardware is not perfect, the software that interfaces to it can not be either.
While Dvorak is usually an idiot and right for all the wrong reasons, or flat out wrong, there is an amount of truth in his analysis of IE.
Lacking, of course, is consideration for its purpose of destroying Netscape to preserve the MS Monopoly. Also, while he stands in 2006 and says that "intenet appliances" never happened, he neglects the role IE played in destroying web standards and making appliances practically impossible.
The thinking being that the Microsoft monopoly platforms would have to run what ever appliance applications were available, with IE, Microsoft was able to keep the APIs and systems subtally different from public APIs. While you could have coded internet appliance applications, it was very difficult. The IE version-o-matic of the late 90s kept *any* interesting content not based on ActiveX out of the mainstream.
So, in the end, the amazing MSnovation to prohibit actual "innovation" worked again.
But, yes, looking over the past 5 or 6 years, Microsoft injured computer innovation with IE, but could not kill it. The browser wars are back, and it is likely that Microsoft can't play the same game twice.
What a looser. Linux was gaining popularity before Oracle ran on it. Yes,
a lot of open source projects have benefited by corporate investment, but
they were there and gaining popularity before corporate investment. Big
corporations benefit from open source, by adding resources, they have
benefitted even more.
Just because they give money, doesn't mean that they run the party. What's
the difference between god and Larry Ellison? God doesn't think he's Larry
Ellison.
Sigh, yes, that *is* the way it is documented. If you would have only google'd for this information before you this exchange it could have saved a lot of time. What I saw as a misunderstanding was in fact merely someone not even educating themselves about the basics of the discussion. The Windows metafile format is old, really old, and there is lots of info available. Try google, it helps.
Secondly, the fact still remains that you are totally confused about pointers. A function pointer holds an address of a function. A data pointer points to the location of data. There is an inherent indirection in a function pointer and it could not possibly be used in the same way for both a function pointer and the address of an actual function.
Maybe you are not a C/C++ guy, but merely casting different pointer types does not invoke any extra functionality, It just tells the compiler how you want to use the value. You easily shoot yourself in the foot if you are even the least bit fuzzy about pointers. That's why the two different modes don't work. The compiler won't fix it for you and you'll crash.
This is silly, as the API is documented, the metafile contains an address. Period. This true and this is how it is documented and this is how it works. There is no way that code, that is implemeted as documented, that reads 4 bytes out of a file, or memory buffer, or whatever, *can* confuse the indirection of a pointer in the way you keep insisting. I have been developing software using C or C++ for about 20 years now and I kind of know what I'm talking about.
// 200 bytes should be enough
In the simplest terms, the metafile AbortProc tag data is an AbortProc *p, NOT an AbortProc p. One way works, one way simply does not. Just because you seem to be very confused about pointer indirection does not mean that the compiler would be as well.
It is impossible to create one path of code that does both with the same execution strategy.
If you disagree, try this:
#include
void foo()
{
printf("It worked\n");
}
typedef void (*myfn)(void);
char buffer[4096];
int main()
{
myfn bar = foo;
(*bar)();
bar = (myfn) buffer;
memcpy(bar, foo, 200);
(*bar)();
}
Again, you seem to be confused about how C/C++ pointers work. You are confusing a "pointer" with a "pointer to a pointer" CODE: // Will contain tag info // Void pointer P points to the data supplied in the file // P Points to address of function // Copies 4 byte address from pfn into fn; // Points to actual code
int len = get_file_length(wmf);
void *wmfbuf = read_file(wmf, len);
int pos=0;
while(1)
{ TAG *tag;
void *p = get_next_record(wmfbuf, &tag, &pos);
switch(tag.type)
{ case SET_ABORT_PROC:{
if(as_documented){
AbortProc ** pfn = (AbortProc **)p;
AbortProc * fn = *pfn;
}
else if(as_exploit){
AbortProc *fn = (AbortProc *)p;
}
break;
}
}
In the above example, the pointer (fn) is initialized with the first four bytes of data from where pfn points. Your argument implies that the compiler will confuse a "AbortProc *fn" and "AbortProc **pfn" which would cause an error.
This is basic C/C++ pointer stuff and I assure you, there are different types of pointers and it is not possible to confuse the two and still have both work. Each behavior MUST be coded separately.
No, you are explaining what you are saying perfectly, it is just that you are incorrect. There is no way that code would "accidentally" be put into the file. It would always be just the 4 byte function pointer. The difference between a call like "DrawText" and "SetAbortProc" is that code is unlike data. Data has some delimiting quality, like a count of bytes or a zero termination. To copy executable code into file would require additional information, starting point (probably the pointer) and count of bytes to copy, which is not present in SetAbortProc, I doubt it is possible to even extract this information in C without some real ugliness. When I talked about DS to CS aliasing I was talking about protected 16 bit mode of the 80286 and 80386. In real mode Windows you could not make an arbitrary far call (32 bit) as Windows moved and delete code segments that were not in use. You needed to make a far call into a thunk which would ensure that your code segment was in memory.
You're not getting it!!
In C "casting" doesn't do magic. In the most basic terms, the correct implementation, you read four bytes from the metafile, and that points to the address of your AbortProc in the system. That is *THE* *DOCUMENTED* behavior of the function.
The exploit implementation is where the code is executed, it is a strange API, it loads the file into RAM and then jumps blindly into the block of code loaded from the file, it is sloppy and dangerous, but *this* is the exploit that is problematic and being discussed.
In fact, in Win16 days, you would have to REALLY go out of your way to do this because have to make a DS to CS alias to allow executon on that segment of memory. (In 80286 potected mode data segment selectors did not allow execution, you had to create a "code segment" to execute it)
The exploit implementation is VERY difficult to maintain over OS, compiler, and language changes for a couple decades. It is not by accident that this function is still there. The question is why is it still there?
You are sort of missing the point, when used as documented, the SetAbortProc contains a pointer to a function. When used as the exploit, it executes the code embedded in the file. There are two distict methods of executing code and can not be handled by the same chunk of code.
You gave this as an exmaple:
int code = readchar();
int length = readint();
void* pointer = get_pointer_to_next_byte();
advance_file_pointer(length);
dispatch_function(code, pointer, length);
The problem is that there seems to be a misunderstanding of pointers in C here.
AbortProc *fn;
read(&fn, sizeof(AbortProc), file);
IS NOT THE SAME AS:
read(pointer, file_size, file);
fn = pointer;
In the first example we are reading sizeof(AbortProc) bytes from the file into the function pointer, which then points to a location in memory as descrived by the data read. In the second example, we are setting the function pointer to the location of memory into which the contents of the file was read.
It can not be done by the same code accidentally.
The problem wth your post is that you state that there is no difference between executing code in a file vs executing a function address. This is incorrect. It is IMPOSSIBLE for code designed to read a pointer out of a file or memory address and call that address to jump to the locaton of what should be a pointer.
These two distinct behaviors must be coded differently and must be maintined differently as compilers, bit depths, and core OS change over time.
I still say the the embedded code aspect of the metafile is damning and unexplained. Waived away, easily, as "lost with the origial programmer," but completely ignoring the almost two decades that the code has been maintained and working.
His technical abilities are solid and his access to NT source is no doubt a great advantage. That being said, writing technical articles is one thing, but he never takes the step to examine *why* microsoft has done something nor does he bring to light any insight about motivations.
In his blog, he dismisses the reason for one of the most damning aspects of the metafile exploit as lost with the original programmer. Ignoring that long since the original developer, the code has to have been maintained, and if maintained, tested, on a progressive line of Windows changes over the years.
If there was no known reason for the code, it is inherently hard to test, it would have been removed had there been no use for it.
While Steve Gibson is a bit of a crank, Mark Russinovich is also a Microsoft Apologist. Here are my problems with the explaination: Reading an address: SetAbortProc * fn; read(&fn, sizeof(SetAbortProc), wmf); (fn)(...) vs Reading code: read(code, bytecount, wmf) SetAbortProc * fn; fn = (SetAbortProc) code; (fn)(...); Even Mark was a little confused about this behavior: "The remaining question is why PlayMetaFile expects the abort procedure to be in-lined in the metafile. It's that fact that allows a hacker to transport malicious code within a WMF file. The actual reason is lost with the original developer of the API" He then goes on to make an excuse for the developer being flexable or something. NO developer would see the utility of embedding code in Windows 3.1 or even Win32 as the code fixups are not made in a data source. In Win16 days, you wouldn't have access to your data segment. If this bug was around in real mode days, you couldn't even be sure your program was in memory without a thunk. It is this feature that is the dangerous and of the most dubious utility, and it is this feature that gets a quickest glossing over. I am reminded of the NSA key BS about Microsoft needing a duplicate key in case they lost the original. Give me a break. Now, I respect Mark Russinovich's technical abilities, but he has, most of the time, been a Microsoft apologist, and I don't think that this piece is any different. There is a feature that allows arbitrary code to be executed, there is no real reason for it being there as developing code to use it would require a different tool chain than that used to create applications. As the Windows API went from 16 bit to 32 bit, from a DOS extender to a VMS hack, this functionality has been maintained, and that would require work as the C language and compilers and bit depths have changed over the years. Sorry, I don't trust Microsoft, if its there and has been maintained for some time, it is there for a reason. What is that reason?
You'd be surprised what a little noteriety would do for some of the troglodyte Linux hackers. (FWIW: I am a hacker, but I have no interest in security. Give me a good parallel processing problem, and I'm all over it.)
You forget: "Microsoft rewrites Windows, ejects the old API but keeps .Net compatibility"
Is at best, a long shot.
You say that Microsoft is sitting on a treasure chest 10 years of "bugfixed, known-to-be-working" code. As a former Windows developer, since version 1.03, and who was a Windows NT kernel developer since NT 3.1 (The first version), I can say I hear what you are saying, but "bugfixed, and known-to-be-working" code is only valuable if it can be said that the foundation of the code is solid. If the foundation of the code is bad, its like putting fresh paint on a house with termites and wood-rot. The core of NT was good when Cutler first worked on it. Since then, Microsoft has compromised every aspect of NT that was good. That valuable "bugfixed" code is mostly code that was in error in the first place. The general design of Win32 (and Win16 prior) is too reliant on little or no security between applications. As long as there is a need for normal users to have "Administrator" rights for their applications to run or install correctly, Windows will always be a disaster.
These debates are as silly as they are pointless. Stored procedures are an important tool within a SQL database. They are part of the SQL standard and should be there. Trying to say they are good or bad is like asking if a socket wrench is good or bad. There is a lot of overlap between what can be done in a "business logic" language, like Java or VB, and what can be done in a SQL stored procedure. Like all "gray area" arguments, the simple problems are a matter of choice as to where you want to solve them and which method is easiest. In the "real world" "real problems" often dictate where they must get solved. When you need a stored procedure, it sucks not to have them. That is why I NEVER use MySQL.