As a work around to the problem you point out you could deny the account
you run the service under Set Value on this key only
(HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer).
There is no value in this key that the account would need to modify once
setup
You should do
This MS bulletin mentions several extended stored procedures are
vulnerable, does anyone have a list or an idea if any of these have by
default exec permissions for the group 'public'?
As stated on http://www.appsecinc.com/resources/alerts/mssql/02-.html
following ext. procedures are
SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507)
[ . . .]
SQL Server service to fail, or to cause code to run in the security
context in which SQL Server is running. SQL Server can be
configured to run in various security contexts, and by default
runs as a domain user.
It appears that the Processes tab is doing a simple filename-based
search, and the Applications tab isn't doing any search at all.
(After all, the 'critical system processes' like Winlogon would never
show up in the Applications tab in the first place, since they don't
have top-level windows
1. Is there any current way of exploiting this vulnerability when
there is no scripting or execution allowed?
I do not think so. Fault is placed in particular ISAPI extension
msw3prt.dll, which by default is run by means of script mapping. If mapping
for this DLL is not configured, it will
t;Good Times" goes real?
It's just an idea - for Juan Cuartango or Georgi Guminski or anybody else
willing to verify it ...
Bronek Kozicki
PS sorry for my poor English
g this vulnerability in the
context of Excel files does not change fact, that the weak point in NOT in
IE, nor in Excel, nor in COM, but still in ther very same place: ODBC Jet
driver.
Regards
Bronek Kozicki
5f8012b3" referenced memory at "0x0004". The
memory could not be "read".
Then I have only "choice" to "terminate the application".
I use Windows NT (international English edtion) + SP5 .
Bronek Kozicki
