What's the risk of changing permissions of the Security Eventlog registry key to IT operations?

Question

Background

Many developers are unnecessarily lowering the security of the event log, or requiring applications to run in Administrator mode just so they can use the event log with this C# or VB code:

  EventLog.[WriteEntry][1]("MyBadApp", "This will cause an exception for ASP.NET and non admins", EventLogEntryType.Error, 10);

.. and then not creating an installer that creates the required registry keys for "MyBadApp"

More information

If that is run under Network Service, ASP.NET, WCF, a service account and is using a non-admin account, the following exception will happen ...but who knows if or where it will be logged (Pasting for Google's sake)

System.Security.SecurityException: The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.
   at System.Diagnostics.EventLog.FindSourceRegistration(String source, String machineName, Boolean readOnly)
   at System.Diagnostics.EventLog.SourceExists(String source, String machineName)
   at System.Diagnostics.EventLog.VerifyAndCreateSource(String sourceName, String currentMachineName)
   at System.Diagnostics.EventLog.WriteEntry(String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID, Int16 category, Byte[] rawData)
   at System.Diagnostics.EventLog.WriteEntry(String source, String message, EventLogEntryType type, Int32 eventID)
   at **YOUR.CUSTOM.BROKEN.CODE.HERE(ResolvedMessageEventSource source, QueuedMessageEventArgs e) in c:\test2\YourProjectHere\Class1.cs:line 116**

 ----  SNIP Possibly more stuff here --
System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
The Zone of the assembly that failed was:
MyComputer

Microsoft is aware of this issue, but it is by design for quick and dirty EventLog access. Every time WriteEntry is called, the system will enumerate the registry and look for the "Sourcename" the application specified. If it doesn't exist then it will be created.

The problem is that during enumeration, the Security log is hit,and an exception is thrown. Developers who don't create an installer, or otherwise create a registry key for "MyBadApp" will fall back on the dynamic event creation will see this issue.

This is by design and affects WriteEntry and less frequently WriteEvent (WriteEvent developers usually create an installer)

Solution

There are 3 solutions I'm aware of:

1. Make the application run as Administrator (bad)

2. Change the permissions on the registry keys

3. Create an installer that makes the registry key for the application (best solution)

Question

What is the worst that can happen for an application that changes the permissions of the Security Registry key?

• Can it read the Security event log?

• Can it change or modify entries of the Security event log?

• Can it spoof security events that aren't its own?

• Can that lead to a DoS?

Answer 1

DO NOT CHANGE PERMISSIONS ON THE SECURITY EVENT LOG.

If you change the permissions on it then any application running as the user with permissions can read it, and possibly write to it if you've given them said permissions. If I recall the registry key uses a SDDL format, and that is very easy to set up incorrectly.

You can't change entries with read or write permissions, unless you have access to the underlying event log file, but that's locked by the system.

Yes it can spoof security events.

It absolutely can lead to a DoS if the log is set up to cause a kernel panic once it's hit it's max size.

In any case, you shouldn't be modifying the registry key directly either. It should be done through WMI or through command line with wevtutil.

An installer (admin user) needs to create the log source before the application runs, or the application needs to dump its events into a predefined source. It's very easy to check if the source exists:

if (EventLog.SourceExists("YourSource")) { /* do your stuff */ }

You can also easily create the source by calling this:

EventLog.CreateEventSource("YourSource", "YourLogName");