Welcome to Smokey's Security Forums.
Guests have only limited access to the board and it's features, please consider registering to gain full access!
Registration is free and it only takes a few moments to complete.

Smokey's Security Forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

According to hundreds of reports posted in the past 48 hours on Russian forums and blogs, there's a new computer worm currently spreading and infecting users on ICQ.

New ICQ Worm Infects Thousands of Users

Multilingual OTL (OldTimer ListIt) Log Analysis * Multilingual OTL Tutorials * OTL Downloads * Malware Removal * Microsoft Security Info & Alert Center * Official Jetico Inc. Support Forums

Share this topic on FacebookShare this topic on MySpaceShare this topic on Del.icio.usShare this topic on DiggShare this topic on RedditShare this topic on StumbleUponShare this topic on TwitterAuthorTopic: Details on the License Logging Service vulnerability  (Read 339 times)

0 Members and 1 Guest are viewing this topic.

ScarlettTopic starter

  • Updates Moderator
  • *
  • Offline Offline
  • location: Cymru
  • Posts: 10749
Details on the License Logging Service vulnerability
« Reply #1 on: November 10, 2009, 09:01:47 PM »
Details on the License Logging Service vulnerability
10 November 2009, 7:00 pm

Today, we released MS09-064 which addresses a vulnerability in the License Logging Service.  In this post, we provide some background on the service and the severity of the underlying vulnerability.

 

Background

License Logging Service (LLS) is a feature that was originally designed to help customers manage licenses for Microsoft server products licensed in the Server Client Access License (CAL) model. See http://support.microsoft.com/kb/824196 for more details.  The service has been removed from the Windows Server product line starting with Windows Server 2008. Of the remaining supported platforms this issue only affects the Windows Server 2000 version of LLS.

 

Why is the bulletin severity “critical”?

The bulletin is marked as “critical” for several reasons:

·         The service is enabled by default on Windows Server 2000.

·         It is accessible by anonymous network connection.

·         The underlying issue can lead to extensive heap memory corruption.

 

What are the mitigating factors?

There are two circumstances though that may lower its severity significantly.

 

First, the most common scenario of LLS feature calls for managing CALs within trusted enterprise environment, which in most cases means that the network access to the server hosting LLS will be limited to the local segment of a network, usually separated from the Internet by a firewall, proxy server, or other barrier.

 

Second, the issue leads to a memory corruption, which based on our analysis is very difficult to turn into remote code execution.

 

Technical details

The root cause of the problem is a lack of string verification for the presence of NULL-terminating characters. An unverified string lacking NULL-termination can be passed to a function, which performs following steps:

·         calculate length of the unverified string,

·         allocate buffer for a new string, using the calculated length and the length of some other string,

·         concatenate two strings in the new buffer.

 

Since the length calculation of the unverified string can run beyond the string buffer (because of missing NULL termination), we may end up with four different scenarios depending on the heap memory layout at the time of execution:

 

1.     During the string length calculation, code runs beyond string buffer and hits an unallocated memory page, causing read access violation.

2.     During the string length calculation, code finds a NULL terminating character beyond the string buffer, returning an exaggerated length. The terminating character falls at lower address than the memory block allocated for the new string. The “exaggerated” string is concatenated with the other string in the new buffer, causing no memory access exception, because the length of the new buffer was calculated using the “exaggerated” length.

3.     In scenario 2, another thread owning the block of memory containing the NULL-terminating character incorrectly used for the length calculation, changes the content of memory right after the length calculation, but before string concatenation. This causes a new buffer overflow during concatenation, leading to semi-controlled heap corruption and/or write access violation.

4.     In scenario 2, the memory block allocated for the new string includes the NULL-terminating character. The character then gets overwritten during concatenation process, leading to extensive memory copying and causing write access violation.

 

Scenario 3 relies on a very narrow race condition and thus any attempt to exploit it is likely to be unreliable.  The only scenario leading to a potentially reliable exploit is scenario 4. This leads us to a conclusion that real-life exploitation of this vulnerability will be less likely.

 

-Greg, MSRC Engineering

 

Source: Security Research & Defense

 

* Permissions
You can't post new topics.
You can't post replies.
You can't post attachments.
You can't modify your posts.
BBCode Enabled
Smilies Enabled
[img] Enabled
HTML Disabled


Except where otherwise stated, all content © 2006 - 2010 Smokey Services™ -- All rights reserved
Design of all board graphics, banners and images by Emma aka Tinker - © 2006 - 2010 Smokey Services™ -- All rights reserved
Smokey's Security Forums is member AQMRB - Alliance of Qualified Malware Removal Boards™, an organisation of Approved Qualified Malware Removal Help & Support Boards
Member ASAP - Alliance of Security Analysis Professionals™

    

  

Smokey's provide fully qualified OTL (OldTimer ListIt) Log Analysis & Malware Removal services in English, German and Spanish language