VERT

XP IPv6 DoS & IPv6 Networking Issues with W2K3 and Ubuntu (Also a DoS)

Tue, 13 May 2008 10:30:19 -0800

Back in May of 2007, I was doing some research into IPv6. I had a single host (Windows XP SP2) and a IPv6 Router (Server 2K3) and I was publishing addresses via the router. As I was publishing addresses, I started to notice that they were continually being added to the XP host; older addresses never replaced newer addresses and there seems to be no upper limit on the number of addresses.

I decided to investigate further and setup a simple loop to publish numerous routes. Interestingly enough every published route was received and recorded by the host. I only tested 7500 addresses but at the end of this I was seeing some interesting results, which I've detailed in the advisory below.

Given the results, I decided to contact the MSRC and report it. Since Microsoft's current stance on Denial of Service being a stability issue and not a vulnerability (I guess we've removed A from CIA), they weren't releasing a security advisory for this but instead mentioned that they'd include a fix in XP SP3. They also asked that I follow their responsible disclosure guidelines and not release details until they had patched it.

Given that XP SP3 is now floating around publically I wanted to blog to mention this issue, so I contacted the MSRC to ensure that the fix had been included. After about a week, the response I received was that due to an extensive bug list, they decided not to include this fix.

Since I had mentioned my desire to blog on this issue, they asked that I send them my blog post for review prior to posting it. Since that's done... I now present you with the mini-advisory that I wrote and shared internally almost 12 months ago. It's nothing amazing on a single XP host but it is obviously an issue.

--- Original Mini-Advisory (Sent to Microsoft) ---

Title:
Minor Denial of Service via IPv6 Address Publication

Background:
An IPv6 Router (in this case a 2k3 server) will publish an address for every route that it knows. There doesn't seem to be a limit on how many IPv6 Addresses can be published. If you continually add new routes, it will continually publish new routes. Every IPv6 device on the subnet will listen for these published addresses and add them to its interface.

What I did:
On my IPv6 Router I setup a simple For loop that would effectively add 9999 x 9999 routes to be published, each route would be advertised to the subnet.

Command:
C:\Documents and Settings\Administrator>for /L %k in (0, 1, 9999) DO for /L %i in (0, 1, 9999) DO netsh interface ipv6 add route 2001:db8:%k:%i::/64 "Local Area Connection" publish=yes

Results:
So far, I've added ~7500 addresses... CPU utilization on my XP machine receiving the addresses never drops from 100%. What's more interesting though is the output of the two commands below:

ipconfig

C:\Documents and Settings\Administrator>ipconfig
Windows IP Configuration
An internal error occurred: The file name is too long.
Please contact Microsoft Product Support Services for further help.
Additional information: Unable to query host name.

netsh interface ipv6 show address

C:\Documents and Settings\Administrator>netsh interface ipv6 show address
Querying active state...
No entries were found.
The file name is too long.

Caveats:
It appears that this only works if the XP hosts are on the network when you are publishing addresses at the time. If you add the addresses and then a new host comes online, it appears to only receive the last ~50 addresses. However if the machine is on the network as each address is published, it seems to obtain every address published and just keeps appending them.

May 2008 Updates:

I decided to check other operating systems to see how they responded. I went with Server 2003 and Ubuntu (and another XP test case). The results were interesting. It seems as though other operating systems have protections against this flood built in. Server 2003 limits itself to 9600 IPv6 Addresses, and Ubuntu limits itself to 16. Meanwhile, after 24 hours of testing (using the simple for loop described above (which has it's own drawbacks, including the requirement that it add each of these addresses to the IPv6 router -- a program designed specifically to flood these multicast packets out would be much more efficient)) I have published over 20K addresses and the XP host is trying it's hardest to pick them all up. ipconfig and netsh are unresponsive the majority of the time (every now and then it'll successfully print the addresses) and my CPU is constantly held at 100% by svchost.exe (running as SYSTEM).

This could be interesting with a large network of XP hosts and a script dedicated to publishing large quantities of IPv6 addresses. Especially since these are small multicast packets with minimal amounts of data contained within them.

While you can't flood the 2K3 and Ubuntu systems, something interesting does happen... when they hit their limit they seem to just ignore future published addresses. This could be a potentially bigger problem then simple CPU exhaustion. I will state first that this discussion could be entirely theoretical at this point, as I had a single test case but here's a thought for you. Ubuntu hits it's 16 address limit and Server 2003 hits it's 9600 address limit, what happens next time a valid address is published? Neither of these hosts updated their address lists as I published new ones, suggesting you could deny hosts from learning new addresses.

This begs the question, which is the bigger security risk? Flooding your client operating system and forcing 100% CPU utilization or ensuring your server environments can't learn new published addresses.

OWASP Toronto Presentation - Building A Web Spider

Thu, 08 May 2008 12:21:15 -0800

A couple of weeks ago I spoke at OWASP Toronto. My goal was to lead a discussion on building a web application spider... what you had to consider, pitfalls to avoid and so forth. I felt like it went fairly well, the discussion lasted about an hour and there was quite a bit of group interaction. I picked up some interesting things from the attendees and I'm hoping that they picked up some interesting ideas from me. At the end of the discussion, I was asked if I could make the slides and the sample source (for a very basic spider) available. So here they are.

PowerPoint Presentation
Simple Spider written in Python

PCI Requirement 6.6 Update Released

Tue, 22 Apr 2008 11:10:01 -0800

It looks like the PCI Security Standards Council has posted their update to Requirement 6.6 (available here). They have provided information above and beyond what I mentioned last week. They have also provided a great deal of clarification around Web Application Firewalls.

Some interesting notes:

Reviews can be performed by qualified internal or external individuals. However, internal auditors should not fall into the same organizational unit as the developers.

There is text that identifies examples of where reviews will meet or exceed the quality of Web Application Firewalls. The two provided examples are:
- Security reviews of source code during the development process.
- Testing for the presence of web application vulnerabilities either manually or via a specialized tool

Testing must occur prior to the Web Application going live (Note: Of course this doesn't mean testing should stop there, on going testing is key. As Braden Williams put it today, "You have to MAINTAIN what is assessed")

Trey Ford has a great write-up and answers some additional questions that people may have... I highly recommend reading it.

Follow-Up: Microsoft Websites Open to Ethical Hackers

Mon, 21 Apr 2008 19:00:37 -0800

I blogged earlier today about this story posted on The Register regarding Microsoft's promise to not sue or press charges against ethical hackers reporting flaws in their websites. It's been picked up by a number of people, including Ryan Naraine, Dave Lewis and LinuxSecurity.com.

I wanted to know more on the subject, so I decided to contact Microsoft directly and ask for official clarification (since I wasn't at Toorcon to hear it first hand). The response came from Bill Sisk, Microsoft Security Response Communication Manager. Bill had the following comment:

Microsoft did not announce anything new at ToorCon Seattle regarding its position on responsible disclosure, but we did mention our industry leading online services acknowledgement, which went public in July of 2007. Because we will not pursue legal action against researchers who report vulnerabilities to us responsibly, we hope to encourage those who want to help us protect customers to feel free to do so without fear of repercussions.
As we have done for many years, we continue to work closely with security researchers and encourage responsible disclosure of vulnerabilities in our products as well as for online services. If a vulnerability is responsibly disclosed, we will publicly credit the researcher for his/her assistance. We believe responsible disclosure serves everyone's best interests, by helping to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities with no exposure to malicious attackers while the update is being developed. For additional information on how Microsoft credits researchers for responsibly disclosed online services security vulnerabilities, visit: http://www.microsoft.com/technet/security/acknowledge/faq.mspx.

So it looks like this has existed for a while, and has just been overlooked (or perhaps forgotten); either way, it's great to see that Microsoft has the FAQ available on their website and, as Ryan pointed out on SecurityWatch, has setup a page to acknowledge people who responsibly disclose vulnerabilities in online services.

Microsoft is OK With You Finding Flaws in their Websites

Mon, 21 Apr 2008 14:08:04 -0800

There's an interesting story up on The Register from Toorcon. Since I wasn't at Toorcon, I can't confirm it, and I haven't seen any other stories that don't solely reference The Register's article.

Katie Moussouris, a Microsoft security strategist, told the crowd that Microsoft would not sue or press charges against ethical hackers who report security flaws in their websites.

This is a huge move in the right direction in my opinion. Web security is something that plagues almost everyone and it's good to see Microsoft making a move to improve their web security. Let's hope that more companies will follow Microsoft's move.

Let's also hope that Microsoft puts out something official on this subject, because so far... the only original piece I've seen is The Register's article.

If more comes on this subject, I'll be sure to blog about.

Marketing FUD or Useful Comparison? You be the judge.

Sat, 19 Apr 2008 10:29:03 -0800

A couple of days ago Digital Bond posted a short blog post on Server 2008 Core. They had written about it previously and done a podcast (One of their partners is developing software to run on Server 2008 Core). One of the common themes for Server 2008 Core is the limited attack surface that it presents, as it essentially "console-only". Actually everyone refers to it as an OS without a GUI, yet cmd.exe is open as a window that you can minimize/maximize and you can run task manager, notepad, regedit and a couple of control panel applets, but close enough I suppose. Also when logging in you get "Preparing your desktop"... really all "GUI-less" means is explorer.exe isn't around. Also folders in C:\Users\administrator: Saved Games, Music, Pictures, Links, Favourites, Videos (etc). Alt+Tab still works as well (with a GUI showing you icons).

Anyways, in this Digital Bond blog post, they talked about how the decreased attack surface meant that out of the 25 security bulletins released by Microsoft only 4 would apply to Server 2008 Core. The problem with that? Only 4 of the advisories applied to Server 2008 at all... so Digital Bond has just said that Server 2008 and Server 2008 Core had the same number of patches.

As a side note the decreased attack surface for Server 2008 Core seems to really be on the client-side. I counted 20+ running services on a fresh install, including services like Remote Registry (which doesn't even run on Vista by default) are running on Server 2008 Core.

The four updates that affected Server 2008: MS08-021 (GDI), MS08-023 (ActiveX Killbits), MS08-024 (IE), MS08-025 (Windows Kernel Privilege Escalation).
The three updates that installed on Server 2008 Core: MS08-021, MS08-024, MS08-025.

So 75% of the patches released for Server 2008 also apply to Server 2008 Core... but let's think about this:

Server 2008 allows you to disable metafile processing, mitigating MS08-021.

Server 2008 has IE7 which has the affected ActiveX control in MS08-023 disabled by default and Yahoo! Music Jukebox wouldn't be installed on a server (unless you weren't using it as a server).

With MS08-024 we're back to IE again... Why are you using IE on your server in the first place?.

With MS08-025 this is local and credentialed, which generally implies insider threat.

So out of the 4 patches, only one isn't mitigated by practical server hardening... and that patch applied to both Server 2008 and Server 2008 Core. I'm not sure why Digital Bond was making a big deal out of "only 4 would apply to Server Core.", one thought might be they are pushing their partners product but a more likely thought is that they were saying *IF* (and that's a big, and useless if) all 25 bulletins applied to 2008, only four would have applied to 2008 Core.

[Disclaimer, I would never attempt to do this if I didn't think it was the only semi-plausible explanation for their report]
Well let's think about that... We can immediately eliminate all the Office patches (Common Sense: You don't install Office on a server). That leaves us with 15 / 25 (10 are pure office only). Out of these 15, we know that MS08-025 existed, and MS08-002 was also privilege escalation and it affected lsass (which exists on Server 2008 Core... So that gives us 2 / 13 / 10 (possible, undecided, impossible). We also saw that the IE patch was installed... so let's accept that one all the way across. That's another 2... bringing us up to 4 / 11 / 10. We know that GDI was installed... that's 5 / 10 /10. I have confirmed that wscript exists (even though it is 5.7... let's follow the rules and include it as a "possibility")... that's 6 / 9 / 10. There are two TCP/IP and one AD, so we'll include those... that brings us to 9 / 6 / 10. Now IIS exists on Server 2008 Core, so we'll have to include those two bulletins. That brings us to 11 / 4 / 10. Now the ActiveX Killbits update wasn't installed -- 11 / 3 / 11, and that leaves us with WebDav Mini-Redirector, OLE Automation and DNS Spoofing. DNS Spoofing we'll put on the yes side... 12 / 2 / 10. Web-Dav redirector I'll assume doesn't exist -- 12 / 1 / 11 and OLE Automation... well the DLL exists in Server 2008 Core... so I'll go yes.. 13 / 0 / 11.

That means that *IF* we had taken this approach to determine the size of the attack surface (which means assuming vulnerable versions of software which don't exist on Server 2008), that 13 out of 25 Bulletins would have applied.

So in the end, I'm not sure how Digital Bond came up with 4... however I'd love it if they shared their process. Does Server 2008 Core have a smaller attack surface... theoretically, however I'm not sure if the attack surface is any less than that of a properly hardened and maintained Server 2008 install. In fact, as I pointed out earlier (with Remote Registry) in some cases it's less secure than previous versions of Windows. This doesn't mean people shouldn't use Server 2008 Core, they should just make sure they have a full understanding of what's happening in their environment and not take advantage of Server 2008 Core as an alternative to hardening their server properly.

Hot off the Press -- PCI 1.1 Requirement 6.6 Finally (and Officially) Clarified!

Wed, 16 Apr 2008 12:16:45 -0800

I just got an email from my director who's attending a PCI event in Las Vegas. It seems that the PCI Standards Council has finally released clarification to the often-debated Requirement 6.6 of the PCI SSC. In this section, the standard currently identifies two options: Application Code Review or implementation of Web Application Firewalls. The PCI DSS Information Supplement was completed in February and has a Release Date of April 15, 2008 (yesterday). It is scheduled for publishing online within the next week or so. Here is a snippet from the document:

The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:
1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

I think that we'll see a lot of good come out of this... it really broadens the options of what companies can and cannot do to satisfy Requirement 6.6. This doesn't mean that static source code review should be forgotten or discarded, only that there's now a cost effective option between the two previous options. This will benefit a number of companies, giving them an alternative that isn't as expensive as a manual source code review and also doesn't depend on the company's specific configuration of a web application firewall (Chris Eng of Veracode has a great post on why WAFs just don't cut it).

This also seems to be the exact opposite of what Jeremiah Grossman interpreted Bob Russo's recent quote as meaning. Instead of narrowing the definition the PCI Standards Council has broadened the definition. I guess this is the update/clarification that they mentioned in their response to Dennis Hurst last year.

Hats off to Dennis Hurst, Jeremiah Grossman and others in the industry, along with the PCI Security Standards Council. Many of us have been lobbying for clarification to these requirements and this is a perfect example of how things can improve if you have input from industry experts and responsiveness from the standards bodies. I won't get into debating the "responsiveness" side of the equation in this post, but the update has been made so let's move forward.

In the end though, it's up to the company interested in becoming PCI certified to decide which approach is the right one to take. While I'm sure a number of companies will appreciate this new option, many will deploy web application firewalls, and I'm sure many will still want the peace of mind offered by an exhaustive static code review.

Upcoming MS Tuesday

Thu, 03 Apr 2008 12:33:23 -0800

From here

We have the following this month:
5 Critical
3 Important

Details:

Bulletin 1 (Critical - Remote Code - Office)
Affects:
- Microsoft Project 2000 SR1
- Microsoft Project 2002 SP1
- Microsoft Project 2003 SP2

Bulletin 2 (Critical - Remote Code - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 3 (Critical - Remote Code - Windows)
Affects:
- VBScript 5.1
- VBScript 5.6
Operating Systems (2000, XP, 2003)

Bulletin 4 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- Affects all Operating Systems as well as the W2K Browsers
Operating Systems - ALL

Bulletin 5 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- IE 7
Operating Systems - ALL

Bulletin 6 (Important - Spoofing - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1

Bulletin 7 (Important - Elevation of Privilege - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 8 (Important - Remote Code - Office)
Affects:
- Visio 2002 SP3
- Visio 2003 SP2
- Visio 2003 SP3
- Visio 2007
- Visio 2007 SP1

Trust Me: DoS is Dead?

Thu, 06 Mar 2008 10:32:50 -0800

Security is an interesting thing... it's a field that leaves a lot open to interpretation and in many ways each vendor is allowed to answer the same question differently. Today we'll ask the question, "What warrants a security advisory?" That seems like a straight forward question, so let's put it to the test with two popular browsers: Microsoft Internet Explorer and Mozilla Firefox. Now I feel as though I should preface this by saying that I use Firefox on a daily basis, but that is only because it is cross platform and I have Windows and Linux at work, and Windows, Linux and OS X at home. However, I'm also a big fan of Microsoft as I think previous posts here, and on my personal blog, have demonstrated. So we're not making war with either side here... we're just examining the different responses to the same question. (Note: Neither Microsoft nor Mozilla were consulted, the responses are just my interpretation of their action/inaction.)

So back to the question, "What warrants a security advisory?"

Let's take a look first at Mozilla Firefox. The Mozilla Products Known Vulnerabilities page is one that I am quite familiar with, and a huge fan of. I love the presentation and the layout. What's interesting is that nearly every release contains a very familiar security advisory title, "Crashes with evidence of memory corruption." When you look inside these, they are essentially stability improvements. Yet Mozilla acknowledges that they can crash the browser and they recognize a crash as a security related issue. Another example, to pick one at random, is "Persistent AutoComplete Denial of Service." In this example, millions of characters typed into a form and stored can cause the browser to hang. Not even a crash this time, simply a hung browser and again Mozilla has decided to address this with a security advisory. It seems to me that Mozilla accepts that a Denial of Service warrants a security advisory.

Next up to bat... Microsoft Internet Explorer. Microsoft seems to have taken a very different approach; Microsoft considers a Denial of Service (or "crash") to be a stability issue. These stability issues are not security issues but rather bugs. I know what you're thinking, quite a few security issues are bugs and I would tend to agree... Microsoft, however, would not. Now you are probably asking what evidence I have that Microsoft considers stability issues to simply be bugs that aren't security related. That's simple. I contacted Microsoft security to report a crash condition with regards to IE7. The crash condition can be reproduced reliably and happens to be discussed (briefly) on a few pages regarding web development. Microsoft's response (paraphrased), "This is a bug, report it to the IE team." (Note: this may actually be an Adobe issue in the end; I didn't pinpoint the line of code in the pages responsible for the crash. However it is specific to IE7, in a specific situation. Which at the very least warrants investigation in my eyes.)

This strikes me as a pretty big distinction between what two vendors warrant worthy of a security advisory versus non-security bugs. For the most part, this isn't the sort of thing that would get under my skin if others in the industry weren't drawing misleading conclusions from it.

In a recent article, a claim was made that IE was the most secure browser of 2007. From what I can see, this was based mostly on the number of vulnerabilities reported in various browsers last year. As a Security Researcher, this irks me to no end to see such a sweeping conclusion thrown out for public consumption without first doing research. I can't imagine someone making such a claim based on a simple vuln count if they knew that Microsoft had redefined DoS conditions as non-Security issues - and I can't imagine someone claiming to be an expert on browser Security without knowing this.

Some may say that this is an isolated case by Microsoft with their browser, but the same trend seems to have emerged in other Microsoft technologies - including XP. The only difference in this case is that the author has web technology tunnel vision. At least in this case, their short sightedness limited how much misleading information they put out there.

At the end of the day, DoS is DoS. If one vendor redefines DoS as a non-security issue, those dishing out Security advice need to apply the same definition to competing products. The last time I checked, Security included consideration of confidentiality, integrity, and availability. Agree or disagree, but apply your definition to all products in the space.

My advice is to be careful about taking opinions from "Security Experts" as gospel. If our ramblings inspire you to dig deeper, then we're doing some good. If they don't, we're all worse off.

Seamless RDP

Sun, 13 Jan 2008 20:44:46 -0800

I was having an issue with rdesktop locking on under Ubuntu, so I did some research... I wasn't running 1.5.0, so I upgraded and while reading I found out about SeamlessRDP.

SeamlessRDP allows you to run indvidual applications via RDP instead of your full Windows Desktop. Cendio, the creator of SeamlessRDP lists the following steps:

Get rdesktop 1.5.0 or later from http://www.rdesktop.org/.
Get the server side component, "seamlessrdpshell". It is available in the seamlessrdp CVS module. You can also download a pre-built binary from http://www.cendio.com/files/thinlinc/seamlessrdp/seamlessrdp.zip . Unpack the files to some directory on the server, such as c:\seamlessrdp.
Run rdesktop with: rdesktop -A -s "c:\seamlessrdp\seamlessrdpshell.exe notepad"

They do forget one key thing:

The user you want to use requires a NoDesktop key set.... This key is found at HKEY_USERS\<USER SID>\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer (if you are logged in as the user). NoDesktop will need to be created as a DWORD Value and set to 1.

You are now ready to run SeamlessRDP... I recommend using the run command box (Generally Alt+F2) rather than a console so that the massive amount of error messages don't scroll across the screen (these error messages are ok to ignore). You can run individual applications as Cendio described above... don't forget to provide the IP Address at the end of the command. However, something I enjoyed doing was running explorer.exe... a Windows start menu appears above your Linux Window Manager menu. You can navigate the start menu and launch applications, running them as if they were local.

Now I was experimenting with this over VPN and I did find it slower than RDP... I'm using Ubuntu and I've noticed that SeamlessRDP doesn't play well with Gnome... a single application runs great but if you want to do the explorer trick, you have to open programs, log off and then log back on, Gnome doesn't seem to properly allocate windows when you launch programs. On a LAN the speed seems to be just fine.

Also with Gnome... You will have redraw issues with your Windows start menu, if you have your Gnome taskbar touching the bottom of the screen... your best bet is to put your Gnome taskbar docked next to your Gnome start menu on the top of the screen.

I'm going to keep playing and I'll post any other tips or tricks that I discover.

Interning with nCircle

Thu, 20 Dec 2007 08:36:35 -0800

As 2007 nears its end, so does my internship with the Vulnerability Engineering and Research Team (VERT) at nCircle. I cannot believe how much I have learned since starting last May. Operating systems I had never heard of, advanced Apache and IIS webserver administration, random protocols (SMB, FTP, HTTP, SSH), Reverse Engineering... it seems like everything but the kitchen sink.

Every other day, a new "high priority" vulnerability was reported that kicked VERT into high gear, sending the team into a dizzying rush to write detection for it. What amazes me is how they can juggle these last-minute high-priority rushes while keeping standard coverage projects going on the side. The VERT members managed to juggle both of these and each were still able to find time to pull me aside and train me in everything from Python to Reverse Engineering.

Unlike my past internships, I was very pleased to be able to have the opportunity to accomplish a wide variety of tasks at nCircle instead of sticking with one task throughout the term. I spent 4 months on the testing (QA) side of VERT, and 4 months on the dev side, giving me the opportunity to doublecheck vulnerability detection rules, and then write my own. I was worried that joining a team like VERT would make them hesitant at using me as a resource due to my comparative lack of knowledge, but thankfully that wasn't the case. I was given work just as challenging as the work I saw them doing, and although it may have taken me a little longer to complete since it was my first time doing it, they were patient enough to wait for me to get it done on my own without butting in and doing it for me. This provided me with a challenging environment (which I love!) giving me a chance to learn... and a chance to get tripped up by their constant quizzes: "Are you SURE it works like that? I already know the answer, but I won't tell you. Figure it out for yourself!"

After working in such a fast-paced environment, I'm not sure how I will be able to transition back to a classroom setting to complete my final 8 months in my Information Systems Security degree. One thing I do know is, the knowledge I've acquired while working on VERT for the last eight months has added more value to my degree than any other classroom semester to date.

Thanks VERT, thanks nCircle, have a great Holiday and see you next year!

--Michael Perklin (aka Steve the Intern)

Patch Tuesday - December 2007

Tue, 11 Dec 2007 12:47:12 -0800

Today we see 7 patches, which fix 11 flaws.

---

MS07-063
SMBv2 Signing Vulnerability - CVE-2007-5351

Executive Summary:
This important security update resolves a privately reported vulnerability in Server Message Block Version 2 (SMBv2). The vulnerability could allow an attacker to tamper with data transferred via SMBv2, which could allow remote code execution in domain configurations communicating with SMBv2.

---

MS07-064
Microsoft DirectX Code Execution Vulnerability Parsing SAMI Files - CVE-2007-3901
Microsoft DirectX Code Execution Vulnerability Parsing WAV and AVI Files - CVE-2007-3895

Executive Summary:
This critical security update resolves two privately reported vulnerabilities in Microsoft DirectX. These vulnerabilities could allow code execution if a user opened a specially crafted file used for streaming media in DirectX. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

---

MS07-065
Message Queuing Service Remote Code Execution Vulnerability - CVE-2007-3039

Executive Summary:
This important security update resolves a privately reported vulnerability in Message Queuing Service (MSMQ) that could allow remote code execution in implementations on Microsoft Windows 2000 Server, or elevation of privilege in implementations on Microsoft Windows 2000 Professional and Windows XP. An attacker must have valid logon credentials to exploit this vulnerability. An attacker could then install programs; view, change, or delete data; or create new accounts.

---

MS07-066
Windows Kernel Vulnerability - CVE-2007-5350

Executive Summary:
This important security update resolves a privately reported vulnerability in the Windows kernel. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full administrative rights.

---

MS07-067
Macrovision Driver Vulnerability - CVE-2007-5587

Executive Summary:
This important security update resolves one publicly disclosed vulnerability. A local elevation of privilege vulnerability exists in the way that the Macrovision driver incorrectly handles configuration parameters. An attacker who successfully exploited this vulnerability could take complete control of the system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

---

MS07-068
Windows Media Format Remote Code Execution Vulnerability Parsing ASF - CVE-2007-0064

Executive Summary:
This critical security update resolves a privately reported vulnerability in Windows Media File Format. This vulnerability could allow remote code execution if a user viewed a specially crafted file in Windows Media Format Runtime. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

---

MS07-069
Uninitialized Memory Corruption Vulnerability - CVE-2007-3902
Uninitialized Memory Corruption Vulnerability - CVE-2007-3903
Uninitialized Memory Corruption Vulnerability - CVE-2007-5344
DHTML Object Memory Corruption Vulnerability - CVE-2007-5347

Executive Summary:
This critical security update resolves four privately reported vulnerabilities. The most serious security impact could allow remote code execution if a user viewed a specially crafted Web page using Internet Explorer. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Q: When is a Vulnerable Application not a Vulnerable Application?

Mon, 10 Dec 2007 08:31:13 -0800

A: When the vulnerable component is a third party addon.

It seems that quite a few people are talking about a Stack Overflow that appeared on milw0rm over the weekend. ISC posted on it, SecurityFocus has added it as a vulnerability and assigned an Bugtraq ID to it and Donna's SecurityFlash has picked it up.

Shortly after the ISC post went up, I sent an email to them via their contact form, letting them know that this wasn't a vulnerability in Windows Media Player 6.4. They have finally updated their content to reflect this, but others still haven't... so consider this an update to all those other sites.

This vulnerability affects the 3ivx codec pack and specifically 3ivx.dll. Windows Media Player 6.4, which is found on all versions of Windows up to, and including, Windows Server 2003 doesn't support natively support mp4 files, which is the file format generated by the PoC.

According to the individual that discovered the vulnerability, the latest release (5.0.1) is vulnerable to this flaw.

CVSSv2 Vector Confusion

Fri, 07 Dec 2007 11:39:16 -0800

CVSSv2 is the Common Vulnerability Scoring System organized by FIRST (http://www.first.org/cvss/cvss-guide.html)

** NOTE: all discussion below is about CVSS Version 2, not Version 1 **

CVSS scores are calculated from CVSS Vectors.
CVSS vectors consist of 3 parts;
- Base Vector
- Temporal Vector
- Environmental Vector

FIRST provides links to CVSS calculators so that you can dynamically rate an unscored vulnerability.
There are at least 2 working CVSS calculators available;
- NIST/NVD
- Information-Technology Promotion Agency, Japan
The NVD link unfortunately goes to their CVSSv1 calculator ... this is where the trouble starts ...

FIRST (the authority on the subject) lists the following Temporal Vector Metrics;
- Exploitability
- Remediation Level
- Report Confidence

A Temporal Vector looks like this;
E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]

Exploitability has the following possible values;
- Unproven (U)
- Proof-of-Concept (POC)
- Functional (F)
- High (H)
- Not Defined (ND)

This is where things really get messy - These are the Vector Definitions as found in 4 specifications:
- E:[U,POC,F,H,ND] (according to FIRST Spec)
- E:[U,P,F,H,ND] (according to NVD)
- E:[U,P,F,H] (according to FIRST Historical)
- E:[U,POC,F,H,ND] (according to ITPA-J)

** NOTE: These are directly from the specifications **

FIRST's Official Spec lists;
- E:[U,POC,F,H,ND]
- With Values: Unproven (U), Proof-of-Concept (POC), Functional (F), High (H), Not Defined (ND)

NVD's Vectors Definition lists;
- E:[U,P,F,H,ND]
- With Values: U = Unproven, P = Proof-of-concept, F = Functional, W = Widespread, ND = Not Defined

FIRST's Historical Section lists;
- E:[U,P,F,H]
- With Values: U = Unproven, P = Proof-of-concept, F = Functional, W = Widespread

ITPA-J's calculator lists;
- E:[U,POC,F,H,ND]
- With Values: Undefined (ND), Unproven, Proof-of-concept, Functional, Widespread

NVD's calculator will only accept H for High, not W for Widespread. It will accept P for Proof-of-concept as well as POC (this permits incorrect data).

NVD CVSSv2 Calculator Tests
[E:W BROKEN]
http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:M/Au:N/C:C/I:C/A:C/E:W/RL:O/RC:C)
[E:H FIXED]
http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:M/Au:N/C:C/I:C/A:C/E:H/RL:O/RC:C)
[E:POC CORRECT]
http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:M/Au:N/C:C/I:C/A:C/E:POC/RL:O/RC:C)
[E:P ACCEPTABLE according to NVD]
http://nvd.nist.gov/cvss.cfm?version=2&vector=(AV:N/AC:M/Au:N/C:C/I:C/A:C/E:P/RL:O/RC:C)

ITPA-J's calculator calls H Widespread and maps W and P to Undefined.

ITPA-J CVSSv2 Calculator Tests
[E:H MISLABELED - shows up as Widespread]
http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/cvss2.cgi?name=CVE-9999-9999-Example&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:TF/RC:UC/CDP:L/TD:H/CR:M/IR:M/AR:H)&g=999&lang=en
[E:W MAPPED to Undefined]
http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/cvss2.cgi?name=CVE-9999-9999-Example&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:W/RL:TF/RC:UC/CDP:L/TD:H/CR:M/IR:M/AR:H)&g=999&lang=en
[E:P MAPPED to Undefined]
http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/cvss2.cgi?name=CVE-9999-9999-Example&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:P/RL:TF/RC:UC/CDP:L/TD:H/CR:M/IR:M/AR:H)&g=999&lang=en
[E:POC CORRECT]
http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/cvss2.cgi?name=CVE-9999-9999-Example&vector=(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:POC/RL:TF/RC:UC/CDP:L/TD:H/CR:M/IR:M/AR:H)&g=999&lang=en

Well now you can see where people might have gotten confused ...

I vote we all just use FIRST's Official Spec
- E:[U,POC,F,H,ND]
- With Values: Unproven (U), Proof-of-Concept (POC), Functional (F), High (H), Not Defined (ND)

---

REFS

FIRST Official CVSSv2
http://www.first.org/cvss/cvss-guide.html#i2.2.1

FIRST Historical CVSSv2
http://www.first.org/cvss/history.html#c7

NVD CVSSv2 Calculator
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2

NVD CVSSv2 Broken Metrics
http://nvd.nist.gov/cvss.cfm?vectorinfo&version=2

ITPA-J's CVSSv2 Slightly Broken Calculator
http://jvnrss.ise.chuo-u.ac.jp/jtg/cvss/cvss2.cgi

XSS: What Type of Vuln Is It?

Thu, 30 Aug 2007 11:17:38 -0800

So an interesting question just came up in the office... Is a XSS a local or remote vulnerability. Now before we get into the discussion, let me clarify local and remote for you.

Local Vulnerability: A vulnerability affecting a client, generally you can think of this as falling into two types. Type 1 is physical access required and Type 2 is user interaction required.

Remote Vulnerability: A vulnerability affecting a remotely available service, or something available via that service.

So... Is XSS a local or a remote? I'll tell you that I'm fairly close-minded on this topic, so unless you've got a fairly compelling reason to argue it's a local, I'll most likely disagree. My answer is remote. Why? The XSS exists in a web page. The web page is hosted on a web server and is remotely available. To me that makes sense, I'm not sure that it can really be disagreed with. An argument for XSS being considered a local is that the client is affected... this seems to make sense. You visit a web page and a pop-up containing 'XSS' suddenly shows up but sit down and consider what happens.

- A Web Application is (poorly) developed.
- The Web Application contains a guestbook that allows for XSS in "signatures".
- A Malicious user visits the guestbook. (Page is properly rendered)
- A Malicious user enters <script>alert('pwned by XSS')</script> into the guestbook.
- An unsuspecting user visits the guestbook (Page is properly rendered) and is greated by a 'pwned by XSS' pop-up.

The malicious user has exploited the vulnerability in the webpage. However a secondary exploit has occurred. This exploit results because the trust relationship between the user and the web server has been violated. The JavaScript engine in the users browser processes the JavaScript while rendering the page and the exploitation of the trust relationship then occurs. This however is a secondary impact, following on the initial exploit of the vulnerable web page.

This was actually covered when CVSS v2 was released. I guess even they had issues answering the question initially:

     Proposal 8
     Proposal 8: Direct and Indirect Impact of Exploitation
     Release Date: 6/16/06
     Status: Approved by CVSS SIG

Our multi-organization scoring comparison effort has revealed that the scoring of vulnerabilities that potentially have an impact on secondary hosts that access exploited servers, such as cross site scripting (XSS) vulnerabilities, is the cause of a large source of CVSS scoring discrepancies between multiple IT security organizations. For example, some analysts score XSS vulnerabilities with respect to the direct impact on the service, and some score them with respect to the indirect impact on an end user of the service.

In order to make scoring consistent and to focus scoring on the software that is directly vulnerable, the CVSS documentation should be updated to reflect that vulnerabilities should always be scored with respect to the impact on the vulnerable service. For the majority of cases CIA will be scored Confidentiality None, Integrity Partial, and Availability None.

So I'm hoping to spur a discussion here, anyone who feels they have a valid reason to call these local, or wants to discuss whether they are local or remote, or wants to discuss whether or not the impact to the user is the initial impact or a secondary impact.