Hi @ll,
here's another (well-known, but undocumented) idiosyncrasy of Windows'
CreateProcess*() functions with a nice side-effect:-P
From http://msdn.microsoft.com/library/ms682425.aspx:
| BOOL WINAPI CreateProcess(
| _In_opt_ LPCTSTR lpApplicationName,
| _Inout_opt_ LPTSTR
Hi @ll,
the Win32 API is full of idiosyncrasies resp. surprising and inconsistent,
poorly tested and documented behaviour.
Just to pick one: NULL pointer as string argument.
0. lstrlen(NULL)
lstrcat(NULL, ...) and lstrcat(..., NULL)
lstrcmp(NULL, ...) and lstrcmp(..., NULL)
This may be a silly question, so I apologize in advance, but that would
exactly be the advantage here? Using a NULL pointer is in most (if not all)
those cases undocumented behavior to begin with. Unless I'm missing
something, the problem is not so much with Win32 as it is with the C
language in
Mario Vilas mvi...@gmail.com wrote:
This may be a silly question, so I apologize in advance, but that would
exactly be the advantage here? Using a NULL pointer is in most (if not all)
those cases undocumented behavior to begin with. Unless I'm missing
something, the problem is not so much
I am truly shocked that seemingly, stuff like this needs to be said in
the year of 2013.
Completely right!
I'd have supposed that things like these should be known by *anyone*
doing anything even remotely similar to software development *at least*
since the end of the 8.3 filename era 15
Hi,
in http://seclists.org/fulldisclosure/2013/Aug/75 I documented
beginners errors (unquoted pathnames containing spaces) not only
in Microsoft products.
Microsofts developer documentation but shows these beginners errors
too (and is inconsistent, even in single topics).
Examples:
I am truly shocked that seemingly, stuff like this needs to be said in
the year of 2013. I'd have supposed that things like these should be
known by *anyone* doing anything even remotely similar to software
development *at least* since the end of the 8.3 filename era 15 years
ago. Are you sure
I'm on the same page as Pascal, what is the point of this? The part
that really stands out for me is how Microsoft is being singled out
here. If it's about their documentation, then it's not really about a
vulnerability. If it's NOT about their documentation, then you'd be
hard pressed to find a
Hi,
since it's start about 20 years ago Windows NT supports (fine grained)
ACLs, including the permission execute file.
In their very finite wisdom Microsoft but decided back then to have
this permission set on EVERY file a user creates (and assumes it is
set on local and remote file systems
Hi Stefan,
... administrative rights for every user account
Hmmm... XP/x64 appears to have a bug such that the second user also
needs to be admin (perhaps XP/x86, too). XP does not recognize the
first account as admin, so the second account cannot be limited (at
least on my test box).
Vista and
Jeffrey Walton wrote:
Hi Stefan,
... administrative rights for every user account
This WAS the default for user accounts back then, and still IS the
default for user accounts created during setup.
Hmmm... XP/x64 appears to have a bug such that the second user also
needs to be admin
Hi,
with Windows XP (about 12 years ago) Microsoft started to develop a
REALLY NASTY habit: they began to install executable files outside
of %SystemRoot%\ and %ProgramFiles%\, in %ALLUSERSPROFILE%\
(since Windows Vista: %ProgramData%\) and even %USERPROFILE%\.
Examples:
*
Hi,
the installation of Microsofts much acclaimed security tool
EMET 3.0 (see http://www.microsoft.com/emet and
http://support.microsoft.com/kb/2458544) creates the following
VULNERABLE registry entry that runs a rogue program C:\PROGRA.EXE
(as well as C:\Program Files.exe on x64) in the security
Hi,
with Windows XP (about 12 years ago) Microsoft introduced the
so-called side-by-side technology to overcome DLL hell.
With side-by-side technology several versions of a DLL can be
installed on a system at the same time, for global use by any
application; the side-by-side store is located in
Hi,
Microsoft distributes (security critical) updates for Windows components
and Microsoft products installed on user systems via Windows/Microsoft
Update and installs them automatically.
Except in some VERY common cases...
For the incorporation of redistributable components like the MSVCRT,
Hi @ll,
many (if not most of the) Windows system utilities and system routines
(including the kernel and its subsystems) as well as many user programs
(including the shell Windows Explorer, Windows Media Player, Internet
Explorer, Microsoft Office, etc.) load libraries/satellites at runtime
via
Hi @ll,
the Microsoft Installer creates for applications installed via an
.MSI the following uninstall information in the Windows registry
(see http://msdn.microsoft.com/library/aa372105.aspx):
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall]
UninstallString=MsiExec.Exe
17 matches
Mail list logo
