[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Privilege Escalation attack


::Save the following as a batch file and execute it.
taskkill /im smcgui.exe /f
goto :here

Now since the smcgui.exe is running in the user account, It will not be denied access to. When the batch file is running, Open the file "c:\Program Files\Symantec\Symantec Endpoint Protection\symcorpui.exe" Even if the password has been set or the administrator has disabled the user to open the GUI, All the conditions will be bypassed. And as I said before, The Help and Support > Troubleshooting will show the server as offline for the client and the NTP will not be visible if its installed.

Thank you.

Regads, Sandeep

From: "Sandeep Cheema" <51l3n7@xxxxxxx>
Sent: Thursday, February 19, 2009 12:50 PM
To: <bugtraq@xxxxxxxxxxxxxxxxx>
Subject: Re: SEPKILL /im SMC.EXE /f

Please note the following. I have reported this to Symantec at


I have reported the second part of this to bugtraq, The first part I will in some time, Once I am done with this thread. The part before that is what this thread looks to be about.



::Save the following as a batch file and execute it.


taskkill /im smcgui.exe /f

goto :here

Its mainly bruteforcing the icon not to appear in the taskbar but doing more than that. The communication with the manager is lost(Though with smc.exe running under system account) and NTP is over and out from the SEP client console while this is running.


With the batch file running, Open the following executable which is the GUI(Not Icon) for SEP

"c:\Program Files\Symantec\Symantec Endpoint Protection\symcorpui.exe"

If you have NTP installed, It would not be there and if you only have the NTP installed, It will say "No Problems detected- No protection technology is installed" and nothing in that board. If you go to help and support > Troubleshooting. The server is offline for the client.

All this might be purely cosmetic but guess there's time to get that patched up before mp2 rolls out.


When the following command line is executed

"c:\program files\symantec\symantec endpoint protection\smcgui.exe" ~

The error is thrown as below which lasts for a split second.

"Serious problem reading transaction from pipe - probable loss of synchonisation a and GetlastError return 6"


and if executed in a batch file in the following way.


::Save the following as a batch file and execute it.


"c:\program files\symantec\symantec endpoint protection\smcgui.exe" ~

goto :here

and run the filemon with the filter as smc.exe, Whenever it tries to access the smcgui.exe. There is a "Buffer Overflow" detected. As I have said at bugtrax as well, I am not sure if the buffer overflow has happened or averted but its all very interesting.

Regards, Sandeep Cheema

Message Edited by S1l3nc3 pl3as3 on 02-18-2009 11:09 PM
Message Edited by S1l3nc3 pl3as3 on 02-18-2009 11:15 PM

From: "Sandeep Cheema" <51l3n7@xxxxxxx>
Sent: Wednesday, February 18, 2009 1:54 PM
To: "Sandeep Cheema" <51l3n7@xxxxxxx>; "Jon Kloske" <jon@xxxxxxxxx>
Cc: <bugtraq@xxxxxxxxxxxxxxxxx>
Subject: Re: SEPKILL /im SMC.EXE /f

In fact looks like Symantec has inherited the bug from Sygate. The original one looks to be patched up though but on similar lines.


Thank you.

Regards, Sandeep

From: "Sandeep Cheema" <51l3n7@xxxxxxx>
Sent: Wednesday, February 18, 2009 1:48 PM
To: "Jon Kloske" <jon@xxxxxxxxx>
Cc: <bugtraq@xxxxxxxxxxxxxxxxx>
Subject: Re: SEPKILL /im SMC.EXE /f

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

"Serious problem reading transaction from pipe - probable loss of
synchonisation a and GetlastError return 6"

When the following batch file is run

"%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

The recordings are from limited user and admin account and have the same

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"
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
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
>>> 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.)