Hi Jon,
Probably there has been some confusion.
The smc.exe -p ~ was a different thread and drwtsn32 was a different one
with different subject lines.
Anyway. This is what my new findings are in continuation with the tilde.
On executing the following command line
"%programfiles%\symantec\symantec endpoint protection\smcgui.exe" ~
The attached error is thrown by the SMGUI.exe which lasts for a split
second.
"Serious problem reading transaction from pipe - probable loss of
synchonisation a and GetlastError return 6"
When the following batch file is run
:here
"%programfiles%\symantec\symantec endpoint protection\smcgui.exe" ~
goto :here
and the filemon is run along with it with the filter as smcgui.exe,
Whenever
the smc.exe tries to access smcgui.exe there is a "Buffer Overflow", I am
not sure if the buffer overflow actually has happened or it has been
avoided.
The recordings are from limited user and admin account and have the same
result.
Also. Worth noting is that once the command is executed then the same
behavior(error) is noted with any parameter passed to smcgui.exe
For example : "%programfiles%\symantec\symantec endpoint
protection\smcgui.exe" test
The same is the case with smc.exe when used with -p
Which indicates that the buffer overflow has happened but I am not
entirely
sure about it.
Thank you.
Regards, Sandeep
--------------------------------------------------
From: "Jon Kloske" <jon@xxxxxxxxx>
Sent: Monday, February 16, 2009 6:53 AM
To: "David Calabro" <dcalabro@xxxxxxxxxxxxxxxxxxxx>; "Sandeep Cheema"
<51l3n7@xxxxxxx>
Cc: <bugtraq@xxxxxxxxxxxxxxxxx>
Subject: RE: SEPKILL /im SMC.EXE /f
Hi David and Sandeep,
Perhaps I'm missing something, but everything you're saying I either
can't reproduce on my test systems or requires administrator privileges
anyway, at which point crashing smc is the least of your problems.
If the Symantec Management Client service was somehow changed from
"smc.exe" to "smc.exe -P" it would effectively prevent the service
from
starting in the first place. Correct?
What are you trying to target with this?
If you can change that portion of the registry, why not replace smc.exe
with "del c:\*.* /q /s /f" or "maliciousprogram.exe" or whatever?
>>> You can kill smc.exe with the help of drwtsn32.exe in the
following
way.
>>>
>>> drwtsn32 -p %pid%
>>> where pid is the process id for smc.exe
There's nothing remarkable about this at all. If you tell Dr Watson to
debug any process id, it's going to end the process. Or at least it did
to half a dozen applications I tested it on :)
Then again, you need administrator privs for this, so really, the same
argument here applies as above. If you have this level of access, why
not just use your administrator privileges more directly instead of
trying to find some pointlessly circumspect method.
I'm not saying you aren't on to something - there does appear to be some
limited amount of instability in the smc.exe binary possibly to do with
paramter validation or parsing or something - but I just can't see at
this stage how it's useful, given that I've been unable to get any of
these problems to affect the actual antivirus process running in the
system account (that's the one that does the actual work), without
administrator privileges (and then as indicated, it's not much of an
exploit if it requires administrative privileges to pull off.)
Regards,
Jon.