RE: Sygate Personal Firewall can be shut down without a need to supply a password - although one is required

["Eitan Caspi" <eitancaspi () yahoo com>]

Hello, Seth,

First of all, I attach for you my latest response to Russ last email
which was not posted yet. Just for you to catch up. Some of things I
wanted to comment on this email of yours are found in the attached
email.

1. You wrote "...you vet... the editor of the newsgroup, and the
vendor".
Facts: 

A. I posted this to Sygate's forum two months ago - no one bothered to
reply.

B. I have spoke about this with Dave from Bugtraq and as you can see -
he approved this note


2. Before I will send issues like this to the email address you sent,
two conditions should be fulfilled:

A. This address should be published someplace obvious on your site - and
not suddenly appear now, in the middle of this issue.
B. The only support options for the free SPF is the forum - where I went
in the first place.
Sorry, but the horses already left the cages... You had the option to
response when the problem was at your home, before it started to
travel...


3. You ignored Russ note of " it is possible for a developer to code
something into their service which, when the service detects a shutdown
request, causes that service to execute some action (such as prompting
for a
password). "

I'm sorry, but I think what I said (and Russ looks like thinking the
same) IS TECHNICALY TRUE.

The scenario you noted is a really lame one: 
A. If the admin is stupid - he doesn't need or able to perform security
in the first place
B. You can easily solve this by forcing the admin to enable a password
at the setup process of SPF. I'm sure you can also enable the password
mechanism for users who are members of only certain security groups. You
can also force a password for starting of the uninstalling process of
SPF.
As you can see - you can think of a lot of options to implement this.


4. I am still not asking for your forgiveness or retracing my claims
since I'm still not convinced I am wrong.


5. No, the new term by you ("users without the rights to stop a
service") is still misleading. No term at all should be used.
The password for exit feature is NOT (until now) related to any user's
security membership.
You claim it was "meant" for specific users - but that claim could not
be found anywhere until your email showed up. You just made it up for
this issue.

6. Sorry, I am certain that this help web page was changed after my
report.
Before I initially posted to Sygate forum, I went to the help web page
to see what Sygate has to say about this - and this feature was not
mentioned, either by text or in the screen shot.

7. You are correct when you are stating that "The reason that the "ask
password while exiting" box is dimmed is that you have to enter a
password before the check box is able to be checked."
But why did you choose to post a screen shot showing this check box as
dimmed?
And why on the same page you don't mention this feature at all?
After all - customers will see the check box on the screen shot but will
not find any description of it. Isn't it strange?

8. I think the debate is (trying) to be professional. But... in the
moment that one side if performing steps that are moving from the
professional side to the (un)moral side - THEY changed the nature of the
debate, and thus they can't claim it is not "professional".

Feel free to attack my credibility if you think it is problematic.
I wrote what I wrote since this is what I think and feel.

I didn't see much honesty from your side and your notes are a mix of
half true and disregarding of the things that does not suit your goals.

Eitan



-----Original Message-----
From: Seth Knox [mailto:seth.knox () sygate com] 
Sent: Monday, December 09, 2002 10:26 PM
To: 'bugtraq () securityfocus com'; 'eitancaspi () yahoo com'
Cc: 'Russ.Cooper () rc on ca'
Subject: RE: Sygate Personal Firewall can be shut down without a need to
supply a password - although one is required

Eitan,

You are welcome. Thank you for taking the time to test Sygate Personal
Firewall. However, in this case, I think you are making an issue out
something that is trivial to anyone who understands the use of rights
and
privileges within the Windows Operating Systems. I suggest that in the
future you vet vulnerabilities you post with security experts, the
editor of
the newsgroup, and the vendor of the related product prior to posting on
a
widely distributed newsgroup such as bugtraq. The editor of NTBugtraq
seems
to feel that same way:

"In this case, Eitan has overstated the severity of the issue, IMNSHO...
While I think its great that people like Eitan are entering into the
security realm, I think properly stating the severity of issues is as
important. When the discoverer puts such comments into their advisories,
it
should be vetted (pre or post publication). I do this with every post to
NTBugtraq, which is why the volume is so low there."

Russ - NTBugtraq Editor

If you wish to submit a vulnerability directly to Sygate for vetting
please
send email to security-alert () sygate com . We also plan to add a note to
the
product documentation and support website explaining that "privileged"
users (users with the right to stop a service) have the right to stop
the
Sygate Personal Firewall service without the password. I would also like
to
clarify the fact that you tested a consumer product not Sygate Secure
Enterprise, which includes an enforcement component that prevents users
(even Administrators) from accessing enterprise and government networks
if
they are not running Sygate Security Agent. I have addressed your
specific
comments individually below.

Seth Knox
Product Manager
Sygate Technologies   


To: 
BugTraq
Subject: 
RE: Sygate Personal Firewall can be shut down without a need to supply
Date: 
Dec 5 2002 10:01PM
Author: 
Eitan Caspi <eitancaspi () yahoo com>


Hello Seth,

Thanks for taking the time to comment about this issue.

1. As you may noticed, I used the term "privileged users". Stopping
service is enabled for the members of the local power users as well, so
the problem range is wider.

*****Response****** 
I agree with this point. Any user with the ability to stop a service can
stop the Sygate Personal Firewall service. 
**************************


2. I will sharpen my point: You are absolutely correct about the fact
that local admins can stop services.

If you will see in my note, I wrote:
" Privileged users CAN START the procedure of stopping the service -
BUT, the application vendor CAN (as part of the overall procedures
performed when an application is being shut down) place a code section
that forces a password prompt at the beginning of the stopping process
and if the password is wrong - to stop the stopping process. "

I ask you this: Do you claim that what I wrote is technically wrong and
it can't be done by sygate?

*****Response****** 
What you wrote is technically wrong. There are a multitude of ways to
stop a
process as a "privileged user". Ultimately, it is impossible for Sygate
to
prevent a user with the rights to stop the service from stopping the
service
by "placing a code section that forces a password prompt at the
beginning of
the stopping process and if the password is wrong - to stop the stopping
process."

Even if we could do this, I don't think we would. Imagine this scenario;
You
are the administrator of a computer, you install Sygate Personal
Firewall
without enabling password protection, a normal user logs in and sets a
password. The result under your proposed implementation would be that
the
administrator of the system wouldn't be able to log into the Sygate
Personal
Firewall or even stop the service. Of course, he could always uninstall
the
application, which brings me back to my original point. Administrators
and
Power users have the right to stop services and uninstall programs
including
Sygate Personal Firewall. If you don't want a user stopping the Sygate
Personal Firewall service, don't give them that Right. 

The NTBugtrack editor has another scenario for you that makes your
argument
a moot point:

"This is a description of a GUI interface, and not the underlying
actions/permissions/rights. IOWs, it is possible for a developer to code
something into their service which, when the service detects a shutdown
request, causes that service to execute some action (such as prompting
for a
password).

This does not mean that the service could not be "stopped". If a user
has
the right to stop a service, they also have the right to modify its
startup
behavior, including setting it to disabled or manual. Since that action
has
nothing to do with the running service, the service could be "stopped"
by
simply changing the setting and restarting the machine...at which time
the
service would not start."
******************************

If this is the claim and it is technically true (I'm not a developer,
but a system admin) - I redraw my claims and ask for your forgiveness.

****Response******
I forgive you but I would appreciate it if you retract your mistaken
claims.
*********************

If you are not able to claim this - then Sygate has just overlooked this
problem and didn't close this breach.


3. Let's be accurate here: YOU added, in your email, the words
"non-administrator". I never claimed the "password for exit" is meant
only for "non-administrator" users. Neither did Sygate!!!- I have seen
the help for the product on your web site - and the password feature was
not even mentioned by text or in the screen shot of the "general" tab!!!
Probably the help pages was not so updated...

*Response******
I apologize. I should not have used the term "non-administrator".
Instead, I
should have used the term "users without the rights to stop a service".
However, I don't think this is material to the argument given the points
made in item 2.
****************

A false sense of security is certainly a vulnerability.


)The above section of the email was written before re-visiting the help
web pages of the product. The following section was written after a
re-visit)



NOW, I have just re-visited the help pages and I must say I'm shocked!!!

Just a day or two ago I visited the web help for the product and the
section describing the "general" tab showed a screen shot of an earlier
version of the product and the whole "password protection" section was
missing from the picture!!! And of course there was no explanation about
this feature!!!

When I entered NOW to the same page 
( http://soho.sygate.com/support/documents/spf_help/general_tab.htm ) -
Suddenly the screen shot is showing the "password protection" feature
and there is even an explanation to the feature.

*Response******
I checked and the page you referred to has not been changed since
October
and it was certainly not changed based on your report.
****************

But that's not all - here comes the best:
The screen shot shows that the "ask password while exiting" is dimmed
and can't be chosen and the password description is not explaining about
this check box at all!!!

*******Response*********
The reason that the "ask password while exiting" box is dimmed is that
you
have to enter a password before the check box is able to be checked. 
***************************

Beside the fact that this is not the actual current application behavior
but only a specially crafted form - what you are doing by this is
arrogantly covering your blame!!!

*******Response********
At this point, you aren't making much sense. The application does
exactly
what we describe on the page:

"Enabling Password Protection will protect your settings from being
changed
by another user. Password Protection will prompt you to enter your
password
every time you access the Sygate Personal Firewall main console."

Notice that this statement does not claim that it is impossible for an
Administrator or Power User to stop the service. However, we will add a
note
on that page to make sure there is no confusion.
***************

I can't express my absolute rejection feelings towards this act!
Security is first of all credibility - and as far as my concern: 
You just lost it!

*****Response******
Let's keep this type of debate professional. I did not attack your
credibility in my response. Please don't attack mine. I think you should
take this a little less seriously if you have "absolute rejection
feelings
towards this act!"
************

Eitan Caspi
Israel

-----Original Message-----
From: Seth Knox [mailto:seth.knox () sygate com] 
Sent: Thursday, December 05, 2002 8:14 PM
To: 'bugtraq () securityfocus com'
Cc: 'eitancaspi () yahoo com'
Subject: Sygate Personal Firewall can be shut down without a need to
supply

If you are an Administrator of a computer, you have the absolute right
to stop any service, including the Sygate Personal Firewall Service,
using the services window or "net stop" command.  This is not a
vulnerability but rather the intended implementation of the Microsoft
operating system.  If the administrator of the computer wants to prevent
other users from stopping the Sygate Personal Firewall Service, they
should not grant that right to other users. As you mentioned in your
email, Sygate Personal Firewall has the option to prevent any
non-administrator from exiting the firewall or stopping the application
from the task menu without a password.  In enterprise and government
organizations, Sygate Secure Enterprise initiates a challenge/response
enforcement protocol that ensures that Sygate Security Agent, as well as
third-party applications, are running and up-to-date before any system
can connect to the network.
 
Seth Knox
Product Manager
Sygate Technologies

----- -----Original Message-----
From: Russ
To: eitancaspi () yahoo com; bugtraq () securityfocus com
Sent: 12/5/02 4:23 PM
Subject: RE: Sygate Personal Firewall can be shut down without a need to
supply a password - although one is required

Eitan said;
"Privileged users CAN START the procedure of stopping the service - BUT,
the
application vendor CAN (as part of the overall procedures performed when
an
application is being shut down) place a code section that forces a
password
prompt at the beginning of the stopping process and if the password is
wrong
- to stop the stopping process."

This is a description of a GUI interface, and not the underlying
actions/permissions/rights. IOWs, it is possible for a developer to code
something into their service which, when the service detects a shutdown
request, causes that service to execute some action (such as prompting
for a
password).

This does not mean that the service could not be "stopped". If a user
has
the right to stop a service, they also have the right to modify its
startup
behavior, including setting it to disabled or manual. Since that action
has
nothing to do with the running service, the service could be "stopped"
by
simply changing the setting and restarting the machine...at which time
the
service would not start.

While I think its great that people like Eitan are entering into the
security realm, I think properly stating the severity of issues is as
important. When the discoverer puts such comments into their advisories,
it
should be vetted (pre or post publication). I do this with every post to
NTBugtraq, which is why the volume is so low there.

In this case, Eitan has overstated the severity of the issue, IMNSHO.
Members of the Administrators and Power Users group have many ways they
can
manipulate the operation of a Windows environment (any version). They
are
"privileged users", and as such, must be endorsed to be trustworthy. If
you
cannot trust individuals using those accounts, then custom privileges
should
be assigned (leaving them out of pre-defined groups). You can stop them
from
shooting themselves in the foot, but you cannot stop them from
intentionally
modifying the operation of the system.

Any expectation that you can is the real "false sense of security".

Sygate have silently acknowledged this by not bothering to prompt for
the
password. This should be clearly documented, and if its not, that then
is
their mistake.

Cheers,
Russ - NTBugtraq Editor

> --- Begin Message ---
>
>
> From: "Eitan Caspi" <eitancaspi () yahoo com>
>
> Date: Sat, 7 Dec 2002 13:32:08 +0200
>
> Well, well, well, I never thought we will get this far, so let's try to
> wrap it up:
>
> 1. The thing that currently worries me the most is not the technical
> side of this issue, but it's moral side:
>
> In all the emails I received (from Russ and others) regarding this issue
> after my last post - NO ONE has commented of the trick sygate pulled by
> changing its SPF help web pages.
> Why is it covering its tracks if it doesn't believe there is a problem
> here?
>
> Think of how do you feel about this step and what is its meaning for
> you.
>
> Security basics are not technical - they are moral and human.
>
> I think it was a foolish step by Sygate - since anyone can download the
> current and latest version (which is the one discussed) of SPF, install
> it and see for himself that the "ask password while exiting" is enabled
> and not closed as on the help page (unless Sygate quickly made a special
> fixed version with the same build number and distributed it...)
>
> All they needed to was to add to the web page an outstanding warning of
> this issue - and this would have been sufficient.
>
>
> 2. Thanks to Russ and all others trying to teach me that admins can do
> EVERYTHING on the machine. I know this and I knew this when I initially
> wrote the first post.
>
> No one of the commenter, including Russ, have said what I suggested for
> Sygate to do is technically impossible or wrong (Russ even backed me up
> on this, Thank You Russ!!!)
> So what I said is TRUE and Sygate simply overlooked this part of its
> application.
>
> My perception of security is that we should strive, in every situation
> to reach higher levels, considering the "big picture" and each "small
> part".
> Thus, I DON'T see the status of admin as the end of the road.
> I posted this issue for sygate to enhance this very specific issue and
> not to make "world peace"...
>
> This is why I appreciate (seriously, not cynically) what Sygate has
> tried to do with the password feature.
> They didn't relied solely on what the OS gives them but added this
> feature and protected the running process. I think they did a good job
> here.
>
> If I would have seen they did not try to implement any extra defense
> mechanisms (in addition to ones supplied by the OS) - I would have never
> post this issue - but since I have seen they DID try (and mostly
> succeeded) to do a better security (after all it is a FW, a security
> application, not a painting application - so it deserves a better
> protection) - I tried to get their attention to this issue.
>
> I have posted this in their support forum more than two months ago, but
> they didn't answer me.
> I think it was fair by me to do this before posting to bugtraq.
>
>
> I know admins can close all the services, make the service startup mode
> manual or disable, uninstall SPF entirely and so on...
> First of all - all this actions are less likely to go by un-noticed if
> there is more than one admin on the machine.
>
> My view is that not all malicious action are "greater than life" -
> sometimes malicious humans just want do something for a specific time
> frame or machine session.
>
> Another possible problem is an un-intentioned action of an admin that
> will come across a local or remote trap that will stop this service and
> thus will use its own privileges to harm him (i.e. when there is only
> one admin and no other (malicious) admins).
> Part of a good practice of a software is to help the user (even an admin
> - after all he's just a man (thank you dolly parton...)) to avoid
> shooting himself in the leg.
>
>
> 3. Regarding Russ's comments in general:
>
> a. You wrote " Eitan has overstated the severity of the issue ".
> Sorry, I don't remember rating this issue.
>
> I did not rate the post since I believe each reader should do it's own
> rating with relevance to it's environment and knowledge. Risk is
> relative (that is my believe).
>
> But, if you still wish for my opinion: I would rate it LOW (due to all
> the things you and others have truly noted about admins abilities).
>
> b. You wrote " Sygate have silently acknowledged this by not bothering
> to prompt for the password " - Are you Sygate's speaker? Or do you know
> the heart and soul of Sygate managers and workers? Who gave you the
> mandate to speak for them?
> The best you can do is speak for yourself, not for others.
> They can post to bugtraq like anyone else.
>
> c. Russ wrote: " While I think its great that people like Eitan are
> entering into the security realm,..." - I think less arrogance will do
> you good.
>
> Security is currently NOT my main job, but part of my many duties as a
> system admin. Believe me - If security was my main job - you would have
> heard more about me.
>
> Yes, I'm relatively new to security, but here is a small list of what I
> have accomplished so far:
>
>
> 1. http://online.securityfocus.com/bid/4053
>
> http://www.microsoft.com/technet/treeview/default.asp?url=/technet/secur
> ity/bulletin/MS02-003.asp
>
> 2. http://online.securityfocus.com/bid/5972
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q329350 (search
> for the word "Eitan")
>
> 3. http://online.securityfocus.com/bid/6280
>
> You can also find some article I have written in
> http://www.themarker.com/eng/archive/one.jhtml (picture included...)
> (filter: Author = Eitan Caspi (second name set), From year = 1999)
>
>
> I searched your site and couldn't find a list of your achievements.
> I would love to see one.
>
>
> d. You wrote "...When the discoverer puts such comments into their
> advisories, it should be vetted (pre or post publication). I do this
> with every post to NTBugtraq, which is why the volume is so low there. "
>
> I suggests you will try and look someplace else for a reason for your
> site's low volume.
>
> Cheers,
>
> Eitan
>
>
> -----Original Message-----
> From: Russ [mailto:Russ.Cooper () rc on ca] 
> Sent: Friday, December 06, 2002 2:24 AM
> To: eitancaspi () yahoo com; bugtraq () securityfocus com
> Subject: RE: Sygate Personal Firewall can be shut down without a need to
> supply a password - although one is required
>
> Eitan said;
> "Privileged users CAN START the procedure of stopping the service - BUT,
> the application vendor CAN (as part of the overall procedures performed
> when an application is being shut down) place a code section that forces
> a password prompt at the beginning of the stopping process and if the
> password is wrong - to stop the stopping process."
>
> This is a description of a GUI interface, and not the underlying
> actions/permissions/rights. IOWs, it is possible for a developer to code
> something into their service which, when the service detects a shutdown
> request, causes that service to execute some action (such as prompting
> for a password).
>
> This does not mean that the service could not be "stopped". If a user
> has the right to stop a service, they also have the right to modify its
> startup behavior, including setting it to disabled or manual. Since that
> action has nothing to do with the running service, the service could be
> "stopped" by simply changing the setting and restarting the machine...at
> which time the service would not start.
>
> While I think its great that people like Eitan are entering into the
> security realm, I think properly stating the severity of issues is as
> important. When the discoverer puts such comments into their advisories,
> it should be vetted (pre or post publication). I do this with every post
> to NTBugtraq, which is why the volume is so low there.
>
> In this case, Eitan has overstated the severity of the issue, IMNSHO.
> Members of the Administrators and Power Users group have many ways they
> can manipulate the operation of a Windows environment (any version).
> They are "privileged users", and as such, must be endorsed to be
> trustworthy. If you cannot trust individuals using those accounts, then
> custom privileges should be assigned (leaving them out of pre-defined
> groups). You can stop them from shooting themselves in the foot, but you
> cannot stop them from intentionally modifying the operation of the
> system.
>
> Any expectation that you can is the real "false sense of security".
>
> Sygate have silently acknowledged this by not bothering to prompt for
> the password. This should be clearly documented, and if its not, that
> then is their mistake.
>
> Cheers,
> Russ - NTBugtraq Editor
>
> --- End Message ---