Date: Thu, 19 Feb 2009 12:50:20 +0530
From: "Sandeep Cheema" <51l3n7@...e.in>
To: <bugtraq@...urityfocus.com>
Subject: Re: SEPKILL /im SMC.EXE /f

Please note the following. I have reported this to Symantec at
https://forums.symantec.com/syment/board/message?board.id=endpoint_protection11&thread.id=25786&view=by_date_ascending&page=2




Symantec,



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.



1)



POC:



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

:here

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.



POC:



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.





2)



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"



http://www.postimage.org/image.php?v=aV2in8dJ



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



POC:



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

:here

"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@...e.in>
Sent: Wednesday, February 18, 2009 1:54 PM
To: "Sandeep Cheema" <51l3n7@...e.in>; "Jon Kloske" <jon@...edu.au>
Cc: <bugtraq@...urityfocus.com>
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.
>
> http://seclists.org/bugtraq/2005/Dec/0249.html
>
> Thank you.
>
> Regards, Sandeep
>
> --------------------------------------------------
> From: "Sandeep Cheema" <51l3n7@...e.in>
> Sent: Wednesday, February 18, 2009 1:48 PM
> To: "Jon Kloske" <jon@...edu.au>
> Cc: <bugtraq@...urityfocus.com>
> 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
>> 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@...edu.au>
>> Sent: Monday, February 16, 2009 6:53 AM
>> To: "David Calabro" <dcalabro@...nsitionalwork.org>; "Sandeep Cheema"
>> <51l3n7@...e.in>
>> Cc: <bugtraq@...urityfocus.com>
>> 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.
>>> 

Powered by blists - more mailing lists