Another vulnerability using SendMessage!
-
Anyone using TTM_GETTEXT? If so, review your code. Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. happy reviewing ;)
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp(); -
Anyone using TTM_GETTEXT? If so, review your code. Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. happy reviewing ;)
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp();Andreas Saurwein wrote: Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT :) Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
-
Andreas Saurwein wrote: Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT :) Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
Tomasz Sowinski wrote: Any malicious app can format your harddrive much easier than cause buffer overflow Wrong. The app might have no privileges at all, but still can modify your applications tooltip to inject code and so gain the privileges of your application.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp(); -
Andreas Saurwein wrote: Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT :) Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
Tomasz Sowinski wrote: Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT hackers love a challenge :-) ASP.NET can never fail as working with it is like fitting bras to supermodels - it's one pleasure after the next - David Wulff
-
Tomasz Sowinski wrote: Any malicious app can format your harddrive much easier than cause buffer overflow Wrong. The app might have no privileges at all, but still can modify your applications tooltip to inject code and so gain the privileges of your application.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp();You're basically describing the shatter-style attack, discussed to death recently. Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
-
You're basically describing the shatter-style attack, discussed to death recently. Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
True. Its just another door which isnt locked.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp(); -
Andreas Saurwein wrote: Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT :) Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
Tomasz Sowinski wrote: Any malicious app can format your harddrive much easier than cause buffer overflow with TTM_GETTEXT That's true only if the OS has no concept of user right (like win 9X). On a multi-user OS the only way to gain access rights that your process didn't deserve is to exploit a bug in another application and run your code using the "host" application access rights. To format a harddrive from a process running logged as "regular" user on windows 200o you've to cause a buffer overflow in an NT service or in a program running logged as Asministrator or use other exploiting tecniques before you can invoke the dangerous API call. For example, many personal firewalls accept or deny connection request based on the process name. In this way iexplore.exe can estabilish a connection on port 80 and myvirus.exe can't (checking only the process name is not very reliable because a malicios process could hook some API and change its process name). Obviously this buffer overflow is not dangerous as a bug in IIS or in a mail/news client because it can't be exploited remotely (via a direct connection or through a malformed e-mail, for example), but it's still dangerous because can be used by a malicious application to increase its access rights. -- Looking for a new screen-saver? Try FOYD: http://digilander.iol.it/FOYD
-
True. Its just another door which isnt locked.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp();BTW: I was playing with LoadLibraryEx - and it's indeed having problems with dialogs and LOAD_LIBRARY_AS_DATAFILE. However, DONT_RESOLVE_DLL_REFERENCES works. Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
-
BTW: I was playing with LoadLibraryEx - and it's indeed having problems with dialogs and LOAD_LIBRARY_AS_DATAFILE. However, DONT_RESOLVE_DLL_REFERENCES works. Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
Tomasz Sowinski wrote: DONT_RESOLVE_DLL_REFERENCES works Now thats weird. I`ll take a look at this. Thanks.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp(); -
Anyone using TTM_GETTEXT? If so, review your code. Any malicious application could modify a tooltips text and thus cause buffer overflows, stack corruptions and code injection. happy reviewing ;)
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp();And it would be *much* easier for the malicious application just to run the code itself. Unless you are expecting some other application to have enhanced privilages which you hope to get at this way...? In that case that's a huge bug in that application rather a vulnerability of sendmessage. There is an article somewhere by microsoft saying that code that creates windows should not be privilaged, and privilaged code should not create windows.
-
And it would be *much* easier for the malicious application just to run the code itself. Unless you are expecting some other application to have enhanced privilages which you hope to get at this way...? In that case that's a huge bug in that application rather a vulnerability of sendmessage. There is an article somewhere by microsoft saying that code that creates windows should not be privilaged, and privilaged code should not create windows.
As long as there are UI applications with elevated privileges, API's designed this way are a problem. Its like saying 'a gun is a security problem because anyone who gets hold of it could use it' but programmers are commonly not (yet) aware of security related problems.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp(); -
As long as there are UI applications with elevated privileges, API's designed this way are a problem. Its like saying 'a gun is a security problem because anyone who gets hold of it could use it' but programmers are commonly not (yet) aware of security related problems.
int x=1, y=5;
x^=y^=x^=y; // whats the content of x and y now?
ClickHereForHelp();And what about applications that open up a socket and accept connections from anyone without authentication? Just because windows allows an app to do something dangerous doesn't mean it';s a flaw in the OS. -- Where are we going? And why am I in this handbasket?