Vulnerability in agent-auth could lead to remote system compromise about ossec-hids

[jrossi]

From: http://ossec-docs.readthedocs.org/en/latest/programs/ossec-authd.html?highlight=authd

There is no authentication involved in this transaction, so it is recommended that this daemon only be run when a new agent is being added.

While i know it is not optimal but it is documented and working as expected. I would love to see code to move this forward but nothing complete has been presented. If you feel this is not strong enough language please submit a pull request to ossec/ossec-docs as this could be make more clean in a lot of places.

Please also note that agent-authd is not started by default for a reason: https://github.com/ossec/ossec-hids/blob/master/src/init/ossec-client.sh#L16

OSSEC should move to using Trusted keys: I agree do you have any coding completed in this area? Would love to review and get this merged.

I want to close this ticket as all items raised should be addressed in other area and I don't want to leave a huge number of ideas / suggestion tickets around as it makes the ticketing system harder to work with and less useful. This is a weird area for orfc:1 and not completely clear: http://ossec-docs.readthedocs.org/en/latest/oRFC/orfc-1.html#development-process I will ponder

cc: @ossec

[mstarks01]

If you close this ticket, then you accept that this vulnerability is acceptable. I don't believe documenting it better and closing the ticket is an acceptable response for an application like OSSEC.

I can certainly suggest improvements to the documentation. It's fine to document that this vulnerability exists and make it clear enough such that the user can choose whether to accept the risk, but it still does not fix the issue. That's just a workaround.

I don't have any code to fix this and won't be submitting any. C is not my area of expertise. But I can recognize insecure behavior and document bugs for the benefit of the project and it's users. A fix was already proposed by mweigel. I suggest you start there.

[jrossi]

Please don't create an implication that a choice in how to manage ticket has anything to do with the vulnerability. You are conflating the issues.

Back to the Isses: it is a lightly documented feature that is not enabled by default and where documented is clear that no authentication is provided. But it's not a vulnerability.

On Apr 5, 2014, at 11:24 AM, "mstarks01" [email protected] wrote:

If you close this ticket, then you accept that this vulnerability is acceptable. I don't believe documenting it better and closing the ticket is an acceptable response for an application like OSSEC.

I can certainly suggest improvements to the documentation. It's fine to document that this vulnerability exists and make it clear enough such that the user can choose whether to accept the risk, but it still does not fix the issue. That's just a workaround.

I don't have any code to fix this and won't be submitting any. C is not my area of expertise. But I can recognize insecure behavior and document bugs for the benefit of the project and it's users. A fix was already proposed by mweigel. I suggest you start there.

—
Reply to this email directly or view it on GitHub.

[mstarks01]

I have contacted Trend representatives and they will handle the vulnerability report as they see fit.

[jrossi]

Ok don't know what that means but sure. Might want to announce this on http://seclists.org/fulldisclosure/

On Apr 5, 2014, at 12:41 PM, "mstarks01" [email protected] wrote:

I have contacted Trend representatives and they will handle the vulnerability report as they see fit.

—
Reply to this email directly or view it on GitHub.

[awiddersheim]

I don't have any code to fix this and won't be submitting any. C is not my area of expertise.

I don't want to speak for the rest of @ossec but it's my opinion that just because most of OSSEC is written in C doesn't mean it has to continue that way. There are plenty of places where writing pieces of OSSEC in C doesn't make sense.

The setup-win.c file is a pretty good example of this. When I first saw it I was like "Why is this in C? Simple batch script would have sufficed."

https://github.com/ossec/ossec-hids/blob/master/src/win32/setup-win.c

The agent portion of ossec-auth might be one of those places. It might not be. I'd just hate to think that people aren't contributing good things just because they think it has to be done in C even though it might not make sense.

Just my 2 cents.

[mstarks01]

@awiddersheim your comments are well received. It's always a good idea to challenge assumptions like this!

[jbcheng]

I would like to handle this concern in an open way. Until a proper fix
becomes available, users of OSSEC need to be cautious about using
agent-auth.
After making sure the documentation is sufficient, we should close this
issue (#178), and focus on the fix (#166)
#166

On Sat, Apr 5, 2014 at 9:41 AM, mstarks01 [email protected] wrote:

I have contacted Trend representatives and they will handle the
vulnerability report as they see fit.

Reply to this email directly or view it on GitHubhttps://github.com//issues/178#issuecomment-39643505
.

JB Cheng le