The presentation "Windows Internals", presented by Cesar Cerrudo, talked about the potential use for a shared "section" of memory associated with a privileged process. These memory regions can be found quite easily using "Process Explorer", a personal favourite Windows tool. Four additional tools were also cited during this presentation: "WinOBJ" which shows object manager namespace information, "ListSS" which lists shared section names, "DumpSS" which dumps shared section data, and "TestSS" which overwrites shared section data. A shared "section" of memory could permit a local unprivileged user the ability to view and/or alter content resulting in a potential crash, influence of functionality, unauthorized access to information, or execution of code at an elevated privilege.

Applications that use shared memory often do not verify integrity of data making it particularly easy to cause undesired conditions that may lead to a crash or execution of code with the privilege of the process. This is because applications tend to trust the content present in shared memory... and why should they not trust it? Access to shared memory should be assigned in a manner that grants an application trust regarding content.

This vulnerability is a serious issue that could easily permit spyware applications and viral software system privileges on a Windows workstation when executed in an unprivileged account. Three suggested solutions: "Set proper permission" (also pointed out above), "Use some synchronization mechanism", and "Validate the data before using it". I believe the appropriate solution is the proper definition of permission such that only trusted access is permitted. Validation of data should only be performed in situations were un-trusted access is a functional requirement. Synchronization would not solve this issue and would only provide unnecessary overhead... Windows has enough overhead.