Online gaming isn't restricted to MMORPGs. Online play includes any sort of network gaming, like deathmatches or racing with a bunch of random people. Basically, anything where a second person can pick up a controller and play with you at home can (well, should) be capable of being played online.
Aside from the other poster's comment, you only have a separate copy of the DLL in the gac for each version. You don't have a copy for each application. You can also remove an old version and/or point an application to the version you want it to use via an app config file.
Why aren't MS patches single discrete objects? One patch for One vulnerability? That way IMHO clears the problem of a "patch" that comes up, is huge, and attempts to fix ten documented vulnerabilities (but knowing the code used in huge projects, it's possibly many dozen fixes at once).
Because a patch replaces an entire binary -- it isn't a binary diff. You can say it's dumb to replace the entire binary, but it's the safest and most reliable course of action.
Let's say for a moment they do as you suggest -- what happens when you have 3 vulnerabilities in the same binary? If you make a "patch" for each of those vulnerabilities, and you install them, you only have the fix for the last vulnerability instead of all 3 vulnerabilities.
Obviously that's bad. So instead you get fixes for multiple problems in the dll at the same time. And any further updates that involve that dll also have those fixes. And so on.
The patents cover VFAT. Document you refer to is titled "FAT File System Technology and Patent License". In other words, you're getting more than just a patent license. Ie: code/specs/other stuff.
No it wasn't. That was the logic of the poster before him (the "warning" Windows would show did not cause windows to function incorrectly, it just made the user think that there was something wrong, just like a "tainted kernel" messages make a user on a linux system think that something is going wrong).
I could never understand why the MSI wasn't XML based from the start. It was written when MS was XML mad, after all.
Actually it wasn't.
Okay, so that explains the why structured storage files were chosen for the base file format, but why use a relational database format in the first place? On this point, my memory was better. Relational databases were just the "in" thing at the time. Picking a relational database file format in the mid-1990s would be kinda' like picking XML as your file format today. I have to wonder if, in five year's time, anybody will be questioning why the heck so many developers picked a verbose, text based file format for so many of their applications. -- robmen
Yet the total weight of the vehicle was somewhere around 2700 lbs. Which isn't bad by todays standard, where it isn't uncommon to find sports coupes that weigh in excess of 3200lbs (350z anyone?)...
Having heard a Delorian in person, the exhaust note is pretty mean sounding.
It is also a lot easier to spin tires on wet pavement (as they did in the movie) than it is on dry pavement -- my 105hp '84 ranger could do a burnout on wet pavement if I tried hard enough...But, if the wet pavement wasn't enough, it would have been easy for them to coat the surface of the tires with something slippery (ex: tire shine) to make things easier...
Write your own default exception handler and have it output a stack trace to your favorite location. As a bonus, you can have it write out a minidum which you can then later load into visual studio for more interactive post-mortem debugging...
1. It looks almost exactly the same in Firebird for me as it does for IE. Which is to say it looks like crap. But to be fair, it looks like crap in both browsers and not just Firebird.
3. No crash here. Though I find it interesting that you would blame the site for crashing the browser instead of a bug in the browser...
Good luck. WiX creates an MSI. An MSI is nothing but a database representing a collection of actions required to install a piece of software (that, an a cab file with the files which need to be installed). It does not build a program which performs an install.
In order to "embrace and extend" it, you'll need to either create an application in KDE-land which can interpret the database, or change the format of stuff WiX generates. Which wouldn't be so much embracing & extending as it would be making different.
I'm not sure about (1), but I doubt it (and parts of IIS (for example) runs in the kernel so even if (1) is true, it doesn't help much).
The reason why I mentioned it is that from looking at the tech docs it appears that there is some way to restrict access to pages based on what mode the processor is in; however, I didn't understand it fully, and it may entirely depend on how the OS is implemented.
Regarding your "well, even if it is it doesn't help" comment, actually it does. It greatly reduces the surface area for such attacks to kernel code. While Windows has had a crapload of security problems, I can't recall one that was related to code running in the kernel.
(2) is very true, but even though it's non-static, it still might be pretty predictable (at least enough that you could unprotect enough pages to be sure that the stack is infact unprotected).
Hmmm... given that (again) I don't know how page table entries are manipulated from userland, I'm wondering if some sort of exception would occur if a process tries to manipulate entries not owned by it...
(3) is also true, but my later comment points out that even if (3) is true, you can still run several calls on the stack which still amounts to running malicious code (it's just a lot more limited than running real code).
I didn't think about that. I suspect the amount of damage that could be done would be greatly reduced though. And it would over the heads of all of the lame script kiddie stuff we've been seeing lately.
And for (4), only the software stack corruption detection would stop this. Even then, software stack corruption detection (like propolice, which I'm sure MS's software is similar to) can be circumvented. How, you ask? clip
It may very well be that MS's technology does generate those numbers at runtime, as I can't really picture any other way to implement that sort of thing (with the below in mind).
Based on some of the discussions I've seen surrounding how to exploit the buffer overflow used by MSBlaster on Win2k3, MS isn't using static data check overflow detection technique. In fact, on Win2k3 machines the technique actually depended on triggering the overflow handler after they had overwritten the overflow handler or the pointer which points to that handler (from what I understand). You may be able to someone mark the page as RWX, but due to the way exceptions are handled you will not be able to jump to any code you placed on the machine. Brings up an interesting question though regarding what happens when the exception handler is in an NX page...
But back to the point, even rearranging the stack to grow up instead of down (therefore making it impossible to overwrite the return address) would prevent smashing data on the stack which could still have bad results. The only real protection is to not use functions (or make functions) that will unlimitedly write to the stack (or the heap). I think having data storage areas prefixed with a size indicator wouldn't be a bad idea, either.
Probably true, but it doesn't do anything for non stack based overflows. I don't think that such a change (stack growing) can be made with the existing architecture. Would be interesting to see if anyone ever modifies a compiler with your other idea in mind.
The NX bit isn't a magic pill that solves all of the problems, but it certainly makes it harder to exploit problems and reduces the potential surface area for attacks. That is never a bad thing.
I didn't say delete all of the files, I said delete files which matched a certain pattern. Or for that matter, the lack of ability to filter such a fiew based on any criteria.
In the case of deleting all files, all that is needed to remain intuitive is an "are you really sure?" prompt, which is not asked for during normal operations.
There are two possible problems I can see with that, though keep in mind that these may not actually be problems as I don't have a complete understanding of how a modern os manages memory...
1) Wouldn't the process need to be running in supervisor mode to manipulate the page translation tables? 2) Isn't the "page" non-static? 3) Doesn't this assume that the process has some sort of method which alters page permissions? I was under the impression that the OS set the page permissions when the app starts, not the app itself. 4) Wouldn't the combination of software stack corruption detection and the NX bit defeat this?
LOL... that's what I get for checking slashdot first thing in the morning...
It's not a real "file manager"
on
3D, FPS File Manager
·
· Score: 3, Informative
From the story: So far only the delete function works.
Except it doesn't. When you shoot a file, it removes it from the display, but not from the drive. This was just someone's program for a school project.
Aside from the fact that it seems very hard to navigate (ie: find what you're looking for), I would think that actually implementing this would be dangerous (whoops, I accidentally shot a file) and not very user friendly (crap, I've got to delete all of the.txt files in this directory with 800 files in it...).
Server downtime Date: Saturday 17th of January 2004 We've had some problems with our server the last few days but it should be fixed now, sorry for the inconvenience it may have caused ...that was, until your server was posted on the frontpage of slashdot...
once it's proven to work, then the bells and whistles get added.
Unfortunately, once you add the bells and whistles you can no longer say with any certainty that the code still "works." Anytime someone touches working code they risk breaking it. Only way to avoid that is testing, which is as much of an inexact science as programming is...
Re:I don't think that I like the idea of MS...
on
Gates on Winsecurity
·
· Score: 2, Informative
This feature will prevent ligitimate apps from running in the following cases:
1) They attempt to write to pages marked as executable instructions (self modifying code, various buffer overruns/heap/stack corruption) 2) They attempt to run code in a page marked as data
Basically, the two patterns listed above are how almost all remote ownage occurs on a box. There are a few legitimate reasons why you'd want to have self modifying code (JIT compilers being the biggest) but they can be worked around. I'd be willing to bet the reason your software is having problems is because there are bugs in the code that do 1 or 2 which do not result in app crashes (or easily repro'd crashes anyway...).
It may not be much fun to fix bugs, but if you're a tester that is what you need to push your devs to do. However, given that most of your customers are probably not using Itanium or AMD64 processors, they won't be effected.
But, I'd think that finding and fixing problems of this sort would be pretty easy if you have a global exception handler that outputs a minidump as part of the exeption handling -- you can create a minidump that saves all of the app memory, the register contents, stack frame, etc. Basically, you can see exactly what the state of the machine was when the crash occured -- or, in even plainer english, you can see what line of code the crash occured on and what the value of every variable was when the crash occured (though if you have a multithreaded app, the other threads are still running before you start the minidump, so the data being modidified by other threads may be different than it was when the crash occured; that generally only matters when you've got a crash caused by cross-threading issues, and generally when you have one of those issues both threads crash so it's pretty easy to figure out what caused it).
Slashdot Mirror
Online gaming isn't restricted to MMORPGs. Online play includes any sort of network gaming, like deathmatches or racing with a bunch of random people. Basically, anything where a second person can pick up a controller and play with you at home can (well, should) be capable of being played online.
Aside from the other poster's comment, you only have a separate copy of the DLL in the gac for each version. You don't have a copy for each application. You can also remove an old version and/or point an application to the version you want it to use via an app config file.
Why aren't MS patches single discrete objects? One patch for One vulnerability? That way IMHO clears the problem of a "patch" that comes up, is huge, and attempts to fix ten documented vulnerabilities (but knowing the code used in huge projects, it's possibly many dozen fixes at once).
Because a patch replaces an entire binary -- it isn't a binary diff. You can say it's dumb to replace the entire binary, but it's the safest and most reliable course of action.
Let's say for a moment they do as you suggest -- what happens when you have 3 vulnerabilities in the same binary? If you make a "patch" for each of those vulnerabilities, and you install them, you only have the fix for the last vulnerability instead of all 3 vulnerabilities.
Obviously that's bad. So instead you get fixes for multiple problems in the dll at the same time. And any further updates that involve that dll also have those fixes. And so on.
The patents cover VFAT. Document you refer to is titled "FAT File System Technology and Patent License". In other words, you're getting more than just a patent license. Ie: code/specs/other stuff.
No it wasn't. That was the logic of the poster before him (the "warning" Windows would show did not cause windows to function incorrectly, it just made the user think that there was something wrong, just like a "tainted kernel" messages make a user on a linux system think that something is going wrong).
So, using your logic, it was ok for early versions of windows to show a warning message when non MS versions of DOS were being used?
Actually it wasn't.
Okay, so that explains the why structured storage files were chosen for the base file format, but why use a relational database format in the first place? On this point, my memory was better. Relational databases were just the "in" thing at the time. Picking a relational database file format in the mid-1990s would be kinda' like picking XML as your file format today. I have to wonder if, in five year's time, anybody will be questioning why the heck so many developers picked a verbose, text based file format for so many of their applications.
-- robmen
It gives you the ability to channel surf without having to wade through commercials if you happen to find a show you like.
Yet the total weight of the vehicle was somewhere around 2700 lbs. Which isn't bad by todays standard, where it isn't uncommon to find sports coupes that weigh in excess of 3200lbs (350z anyone?)...
Having heard a Delorian in person, the exhaust note is pretty mean sounding.
It is also a lot easier to spin tires on wet pavement (as they did in the movie) than it is on dry pavement -- my 105hp '84 ranger could do a burnout on wet pavement if I tried hard enough...But, if the wet pavement wasn't enough, it would have been easy for them to coat the surface of the tires with something slippery (ex: tire shine) to make things easier...
Write your own default exception handler and have it output a stack trace to your favorite location. As a bonus, you can have it write out a minidum which you can then later load into visual studio for more interactive post-mortem debugging...
The patent doesn't even cover the filesystem. It covers a specific method of storing long filenames on a FAT filesystem.
It effects nothing unless you want your device to interact with long file names on a FAT filesystem.
1. It looks almost exactly the same in Firebird for me as it does for IE. Which is to say it looks like crap. But to be fair, it looks like crap in both browsers and not just Firebird.
3. No crash here. Though I find it interesting that you would blame the site for crashing the browser instead of a bug in the browser...
Good luck. WiX creates an MSI. An MSI is nothing but a database representing a collection of actions required to install a piece of software (that, an a cab file with the files which need to be installed). It does not build a program which performs an install.
In order to "embrace and extend" it, you'll need to either create an application in KDE-land which can interpret the database, or change the format of stuff WiX generates. Which wouldn't be so much embracing & extending as it would be making different.
Aside from my doubts that the force imparted by a bullet on a multi-ton object would cause it to move a few miles between shots at the same target...
Shoot two bullets in opposite directions.
I'm not sure about (1), but I doubt it (and parts of IIS (for example) runs in the kernel so even if (1) is true, it doesn't help much).
... given that (again) I don't know how page table entries are manipulated from userland, I'm wondering if some sort of exception would occur if a process tries to manipulate entries not owned by it ...
The reason why I mentioned it is that from looking at the tech docs it appears that there is some way to restrict access to pages based on what mode the processor is in; however, I didn't understand it fully, and it may entirely depend on how the OS is implemented.
Regarding your "well, even if it is it doesn't help" comment, actually it does. It greatly reduces the surface area for such attacks to kernel code. While Windows has had a crapload of security problems, I can't recall one that was related to code running in the kernel.
(2) is very true, but even though it's non-static, it still might be pretty predictable (at least enough that you could unprotect enough pages to be sure that the stack is infact unprotected).
Hmmm
(3) is also true, but my later comment points out that even if (3) is true, you can still run several calls on the stack which still amounts to running malicious code (it's just a lot more limited than running real code).
I didn't think about that. I suspect the amount of damage that could be done would be greatly reduced though. And it would over the heads of all of the lame script kiddie stuff we've been seeing lately.
And for (4), only the software stack corruption detection would stop this. Even then, software stack corruption detection (like propolice, which I'm sure MS's software is similar to) can be circumvented. How, you ask? clip
It may very well be that MS's technology does generate those numbers at runtime, as I can't really picture any other way to implement that sort of thing (with the below in mind).
Based on some of the discussions I've seen surrounding how to exploit the buffer overflow used by MSBlaster on Win2k3, MS isn't using static data check overflow detection technique. In fact, on Win2k3 machines the technique actually depended on triggering the overflow handler after they had overwritten the overflow handler or the pointer which points to that handler (from what I understand). You may be able to someone mark the page as RWX, but due to the way exceptions are handled you will not be able to jump to any code you placed on the machine. Brings up an interesting question though regarding what happens when the exception handler is in an NX page...
But back to the point, even rearranging the stack to grow up instead of down (therefore making it impossible to overwrite the return address) would prevent smashing data on the stack which could still have bad results. The only real protection is to not use functions (or make functions) that will unlimitedly write to the stack (or the heap). I think having data storage areas prefixed with a size indicator wouldn't be a bad idea, either.
Probably true, but it doesn't do anything for non stack based overflows. I don't think that such a change (stack growing) can be made with the existing architecture. Would be interesting to see if anyone ever modifies a compiler with your other idea in mind.
The NX bit isn't a magic pill that solves all of the problems, but it certainly makes it harder to exploit problems and reduces the potential surface area for attacks. That is never a bad thing.
I didn't say delete all of the files, I said delete files which matched a certain pattern. Or for that matter, the lack of ability to filter such a fiew based on any criteria.
In the case of deleting all files, all that is needed to remain intuitive is an "are you really sure?" prompt, which is not asked for during normal operations.
There are two possible problems I can see with that, though keep in mind that these may not actually be problems as I don't have a complete understanding of how a modern os manages memory ...
1) Wouldn't the process need to be running in supervisor mode to manipulate the page translation tables?
2) Isn't the "page" non-static?
3) Doesn't this assume that the process has some sort of method which alters page permissions? I was under the impression that the OS set the page permissions when the app starts, not the app itself.
4) Wouldn't the combination of software stack corruption detection and the NX bit defeat this?
LOL ... that's what I get for checking slashdot first thing in the morning ...
From the story: So far only the delete function works.
.txt files in this directory with 800 files in it...).
Except it doesn't. When you shoot a file, it removes it from the display, but not from the drive. This was just someone's program for a school project.
Aside from the fact that it seems very hard to navigate (ie: find what you're looking for), I would think that actually implementing this would be dangerous (whoops, I accidentally shot a file) and not very user friendly (crap, I've got to delete all of the
Server downtime ...that was, until your server was posted on the frontpage of slashdot...
Date: Saturday 17th of January 2004
We've had some problems with our server the last few days but it should be fixed now, sorry for the inconvenience it may have caused
However, there's nothing stopping this:
[junk][RWX][page][page permission set call][filler][pointer to code ][code ]
I'm afraid I don't understand what you're trying demonstrate here.
once it's proven to work, then the bells and whistles get added.
...
Unfortunately, once you add the bells and whistles you can no longer say with any certainty that the code still "works." Anytime someone touches working code they risk breaking it. Only way to avoid that is testing, which is as much of an inexact science as programming is
This feature will prevent ligitimate apps from running in the following cases:
1) They attempt to write to pages marked as executable instructions (self modifying code, various buffer overruns/heap/stack corruption)
2) They attempt to run code in a page marked as data
Basically, the two patterns listed above are how almost all remote ownage occurs on a box. There are a few legitimate reasons why you'd want to have self modifying code (JIT compilers being the biggest) but they can be worked around. I'd be willing to bet the reason your software is having problems is because there are bugs in the code that do 1 or 2 which do not result in app crashes (or easily repro'd crashes anyway...).
It may not be much fun to fix bugs, but if you're a tester that is what you need to push your devs to do. However, given that most of your customers are probably not using Itanium or AMD64 processors, they won't be effected.
But, I'd think that finding and fixing problems of this sort would be pretty easy if you have a global exception handler that outputs a minidump as part of the exeption handling -- you can create a minidump that saves all of the app memory, the register contents, stack frame, etc. Basically, you can see exactly what the state of the machine was when the crash occured -- or, in even plainer english, you can see what line of code the crash occured on and what the value of every variable was when the crash occured (though if you have a multithreaded app, the other threads are still running before you start the minidump, so the data being modidified by other threads may be different than it was when the crash occured; that generally only matters when you've got a crash caused by cross-threading issues, and generally when you have one of those issues both threads crash so it's pretty easy to figure out what caused it).