Windows XP SP2 may break certain apps
-
-
-
Jim Crafton wrote: Anybody heard about this[^]? Old news. MSDN has had technical details since October. (See here[^] and here[^] (There may be more links but these are the only two I've had bookmarked) I believe the beta period for SP2 is going to be lengthy, after all Microsoft built its market on backwards compatability and making sure that even the most badly written apps would keep working. Michael But you know when the truth is told, That you can get what you want or you can just get old, Your're going to kick off before you even get halfway through. When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
Michael P Butler wrote: beta period for SP2 When? They stress testing, but we need to get the beta before we can test. Taking a course is all well and good but no substitute for the real deal. Hopefully were going to get enough lead time for this.
There is much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community. - Oscar Wilde -
Anybody heard about this[^]? Anyone have any apps that this may affect? The short summary is that it would appear to mostly affect code that uses DCOM, RPCs, certain kind of memory access (they mention that .Net runtimes had to be adjusted/revamped due to this), Windows FireWall. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
Jim Crafton wrote: certain kind of memory access (they mention that .Net runtimes had to be adjusted/revamped due to this), The heap and the stack (if the CPU allows) memory pages are not marked as executable anymore. This will eliminate most buffer and integer overflows, even if the software is buggy. [Better late than never.] This break almost any application that generates code on-the-fly, e.g., JIT compilers. That's why .Net have a JIT compiler (a patch, actually), and all modern virtual machines (JVM, parrot, etc). will need to explicitly mark those memory pages as executable. Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
-
Jim Crafton wrote: certain kind of memory access (they mention that .Net runtimes had to be adjusted/revamped due to this), The heap and the stack (if the CPU allows) memory pages are not marked as executable anymore. This will eliminate most buffer and integer overflows, even if the software is buggy. [Better late than never.] This break almost any application that generates code on-the-fly, e.g., JIT compilers. That's why .Net have a JIT compiler (a patch, actually), and all modern virtual machines (JVM, parrot, etc). will need to explicitly mark those memory pages as executable. Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski
Daniel Turini wrote: if the CPU allows That's the real kicker. Since x86 doesn't have a separate Execute permission for memory, SP2 won't magically fix stack-based attacks, IIUC. It's worth nothing that ATL itself is affected, because it uses a bit of code, constructed at runtime, to connect an
HWNDto its correspondingCWindowImplobject. MS will obviously have a lot of app compat work ahead of them since they can't afford to break every binary out there that uses the ATL window classes. --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer. -- Michael P. Butler in the Lounge -
Anybody heard about this[^]? Anyone have any apps that this may affect? The short summary is that it would appear to mostly affect code that uses DCOM, RPCs, certain kind of memory access (they mention that .Net runtimes had to be adjusted/revamped due to this), Windows FireWall. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
This may be of some help Training on sp2[^]
Interviewer (me) : "Did you install Linux all my yourself?" Candidate : "Yes i installed Linux all my yourself."
-
Daniel Turini wrote: if the CPU allows That's the real kicker. Since x86 doesn't have a separate Execute permission for memory, SP2 won't magically fix stack-based attacks, IIUC. It's worth nothing that ATL itself is affected, because it uses a bit of code, constructed at runtime, to connect an
HWNDto its correspondingCWindowImplobject. MS will obviously have a lot of app compat work ahead of them since they can't afford to break every binary out there that uses the ATL window classes. --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer. -- Michael P. Butler in the LoungeMichael Dunn wrote: Since x86 doesn't have a separate Execute permission for memory, SP2 won't magically fix stack-based attacks I dont think there is any sp2 for x86 machines. :-) Michael Dunn wrote: to connect an HWND to its corresponding CWindowImpl object. Whats wrong in that ? many non ATL applications do the same thing i suppose.
Interviewer (me) : "Did you install Linux all my yourself?" Candidate : "Yes i installed Linux all my yourself."
-
Michael Dunn wrote: Since x86 doesn't have a separate Execute permission for memory, SP2 won't magically fix stack-based attacks I dont think there is any sp2 for x86 machines. :-) Michael Dunn wrote: to connect an HWND to its corresponding CWindowImpl object. Whats wrong in that ? many non ATL applications do the same thing i suppose.
Interviewer (me) : "Did you install Linux all my yourself?" Candidate : "Yes i installed Linux all my yourself."
You quoted the wrong part of my post. Michael Dunn wrote: a bit of code, constructed at runtime It's code put in memory that's allocated at runtime, and then executed... exactly what a buffer overrun attack does. --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Laugh it up, fuzzball.
-
FWIW, the article says Visual Studio products will be updated to address the compatibility issues. Of course, it remains to be seen if VS6 is still supported.
LunaticFringe wrote: Of course, it remains to be seen if VS6 is still supported. From this page[^]: "Tools released prior to VS .NET 2002 will not be serviced to address XP SP2." :(( --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer. -- Michael P. Butler in the Lounge
-
LunaticFringe wrote: Of course, it remains to be seen if VS6 is still supported. From this page[^]: "Tools released prior to VS .NET 2002 will not be serviced to address XP SP2." :(( --Mike-- Personal stuff:: Ericahist | Homepage Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ ---- Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer. -- Michael P. Butler in the Lounge
Whatever happened to the illusive SP6 for VS6. Regards, Kannan