Vulnerability Analysis Blog

Recommendations to vendors for communicating product security information

2008-11-20T21:10:00Z

Hi, this is Chad Dougherty of the Vulnerability Analysis team. One of the important roles that our team plays is coordinating vulnerability information among a broad range of vendors. Over the years, we have gained a considerable amount of experience communicating with vendors of all shapes and sizes. Based on this experience, we can offer some guidance to vendors about communicating product security issues.

]]> Just to be clear, we're talking about product security as opposed to security products. Product security involves vulnerabilities caused by programming or design defects, insecure default or recommended deployment configurations, and other similar issues. These issues potentially affect any product offered by a vendor, including security products such as firewalls, antivirus, and authentication services. This distinction is likely obvious to most readers, but we've seen confusion about it before so it makes sense to clarify.

First, let's address the topic of receiving information about product security. Vendors should provide a persistent and reliable mechanism for researchers to report vulnerabilities. We agree with statements that, for most vendors, it's a matter of "when" you'll receive a report of a vulnerability affecting your products, not a matter of "if." Here are some specific recommendations:

Provide an easily identifiable role email address specifically for product security issues
In our experience, it's extremely beneficial for the vendor to provide a role email address (e.g., a shared mailbox or an alias) for receiving information. Pick an intuitive and memorable name for the role address, such as "product-security@", "security-team@", "security-response@", or "secure@". Note that "security@" may not be a viable option because IETF RFC 2142 suggests using that mailbox name for reporting or inquiring about network operational security issues. Sites that have implemented the recommendations in this RFC may have already allocated that name, and external sites that are familiar with the recommendation may resist sending other types of messages to that address.

Even if this address only has a small number of recipients, having a fixed point of contact is valuable to external parties. Avoid using individuals as direct points of contact because of the potential problems that can be caused by job changes. Vulnerability reporters get frustrated when messages to individuals bounce or when they learn that the individual is no longer connected with the product(s) in question. While there is some additional management overhead in maintaining a role address, our experience indicates that it's a worthwhile investment. Giving members of the product security group the ability to respond from this role address provides additional consistency to external parties.

We discourage the use of standard email addresses such as "info@", "support@", and "webmaster@" for the security point of contact because security reports sent to these addresses can easily be overlooked or mishandled.

Provide a web-based reporting form
A web-based reporting form allows vendors to collect reports in a well-structured manner so that the reports can potentially be searched and managed more efficiently. The form also provides a slightly easier mechanism for vulnerability reporters who may wish to remain anonymous. You may want to consider our vulnerability reporting form for ideas about how to construct your own page.

Use cryptography if possible
The vulnerability reports you will receive may contain sensitive information that could be damaging to users or customers if it were exposed to an unauthorized source. Publishing an encryption key corresponding to the role address mentioned above allows researchers, especially those that consider confidential reporting part of the responsible disclosure process, to securely communicate vulnerability reports. If you think the importance of crypto in the vulnerability reporting process is exaggerated, consider this example: We once sent an encrypted mail containing sensitive information to an external researcher. We received a response from the individual telling us how relieved he was that we encrypted the message because his ISP's POP server was discovered to be compromised not long after we sent the message. Disclosure of the information would've had negative implications for a considerable number of parties.

We use PGP in our processes, but vendors may choose to offer PGP, S/MIME, or both. Maintaining crypto keys also lets vendors sign patches, support bulletins, or advisories. Users can then verify the authenticity of these publications before taking any of the actions they prescribe. Signing can be done with the same key used to receive reports or with a separate signing-only key, depending on the key management practices a vendor chooses to follow. As with the email alias mentioned above, there is some additional overhead in maintaining keys; however, it's been our experience with this, too, that the benefits can outweigh the costs if managed appropriately. The U.S. National Institute of Standards and Technology (NIST) maintains some good resources for key management policies.

Note that we haven't provided any recommendations here about what vendors should actually DO when they receive product security reports. That is a separate topic that we'll try to cover in a future post.

Because communication should be a bidirectional process, let's next consider the publication of product security information. Here are some specific recommendations:

Provide a "slash security" web page
One of the first places users and potential vulnerability reporters will visit to learn about a vendor's product security is the "/security" page on the vendor's main website (e.g., "http://www.example.com/security"). Ideally, this page will be the primary focal point for everything related to product security. We recommend that it contain or refer to, as appropriate, the following content:
- product security bulletins and advisories
- product security contact information, including all of the resources described above
- security patches and updates
- documents (e.g., whitepapers, FAQs, support bulletins, electronic books) describing best practices for secure deployment or operation
- documents describing secure development practices involving relevant products

In some cases, vendors have already devoted the "/security" page to their security product offerings (recall the distinction we described above). Vendors often have a lot of time and money invested in their site layout, so it's unreasonable to expect them to redesign. In these cases, we encourage vendors to include a reference to product security somewhere on the "/security" page, possibly redirecting to a "/support/security" or "/product-security" page, for example. Having "Security" as a dropdown option from a "Support" menu is also helpful.

We have received positive feedback about vendors that provide good product security pages, and, from a public perception standpoint, it's perhaps the single most valuable security-related resource you can provide.

Offer security mailing list subscription
Sending copies of security advisories (or notifications of their availability on the web) to a mailing list is an effective way to get your users and customers to take action in mitigating a vulnerability. We regularly tell users to subscribe to this type of mailing list for the products they use whenever the lists are available. As with other publications mentioned above, email messages sent to these lists should be cryptographically signed to let users verify the authenticity of the message before taking action. A common technique attackers use is to send spoofed "security advisory" emails that contain malicious code in the form of "security patches." To confirm authenticity, signing is crucial if you intend to email information to customers.

We recognize that it may be counterproductive for vendors of specialized products or those that are used exclusively in critical deployments to publish product security information so broadly. In these cases, we encourage vendors to contact known customers directly or provide information in a way that is restricted to existing customers.

One of the underlying themes in this post is the recommendation to centralize points of contact as much as possible. For vendors that have a small or closely related product lines, this centralization can be a straightforward process. However, we understand that many vendors are conglomerates that have a large number of independent divisions. We've dealt with instances where one affected product division had no idea another affected product division even existed. Mergers and acquisitions present another challenge to centralization. The general recommendation we can provide in these cases is to still create points of contact at the coarsest level possible. For example, a company with a network equipment division based in the U.S. and an automation systems division based in Germany might choose to set up "www.bigcorp-networks.example/security/" and "www.bigcorp-automation.de.example/security/" and ideally have links to both of these pages at "www.bigcorp.example/security/". The same redundancy should apply to email contacts.

Vendors' attention to product security is receiving increased scrutiny in security and IT communities. Presenting organized methods for communicating product security information is an important element to demonstrating to customers (both current and potential), security researchers, the media, and the general public that you have at least some awareness of and commitment to security.

Filtering ICMPv6 using host-based firewalls

2008-11-07T16:40:00Z

Hey, it's Ryan. This blog entry contains some quick recommendations about filtering certain ICMPv6 types using two host-based firewalls—Linux ip6tables and Microsoft Vista's advfirewall. If you have suggestions or other ideas, let me know.

]]> ICMPv6 is a protocol that is an integral part of IPv6. ICMPv6 is defined in RFC 4443, and additional functionality is described in later RFCs. IANA maintains a list of ICMPv6 types with links to the corresponding RFCs. It's not easy to have a functioning IPv6-enabled network without allowing some ICMPv6 types, so below are some examples of how to filter ICMPv6 on hosts using ip6tables and the Vista firewall.

Consider these three disclaimers before reading further:

Don't use any of these rules in production without testing.
These rules may or may not apply to link local addresses. Proceed with caution.
The examples in this entry are not complete. More complete rules are available.
The ICMPv6 types listed below can be represented by either rules or type codes.

When it comes to building rules, RFC 4890, "Recommendations for Filtering ICMPv6 Messages in Firewalls," has done most of the hard work for us. Looking at section 4.4 and its subsections (we're focusing on host-based firewalls), various ICMPv6 types are assigned to four categories:

Traffic That Must Not Be Dropped:
Types 1,2,3,4,128,129,130,131,132,143,148,149,151,152,153,133,134,135,136,141,142
Traffic That Normally Should Not Be Dropped:
Types Type 3 - Code 1, Type 4 - Code 0
Traffic That Will Be Dropped Anyway -- No Special Attention Needed:
Types 138,144,145,146,147
Traffic for Which a Policy Should Be Defined:
Types 137,139,140,5-99,102,126

The following example rules do not attempt to cover all the advice in RFC 4890. Instead, we'll get you started with some rules that take advantage of some of the new features offered by IPv6.

First, let's set a default deny policy:

ip6tables -P INPUT -j DROP

ip6tables -P OUTPUT -j DROP

The "Traffic That Must Not Be Dropped" section lists echo request (128) and echo response (129). An attacker could use echo requests (pings) as a DoS attack vector, so we might want to block or limit these requests. Since we're talking about host-based firewalls, we can't stop echo requests from reaching us, but we can limit how many of them we respond to:

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -j ACCEPT

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -j ACCEPT

If our host uses DHCPv6 or we manually assign an IPv6 address and gateway, we don't need stateless auto-configuration. We can drop router advertisements and block router solicitations.

You could disable the processing of router advertisements in the kernel using sysctl, and this traffic is dropped by the default policy. For practice, let's reject instead of drop (note that these rules violate RFC 4890 and will break stateless autoconfig):

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 133 -j REJECT

ip6tables -A INPUT -p icmpv6 --icmpv6-type 134 -j REJECT

The default setting of the hop limit field is usually set to 255 and gets decremented by one every time a router forwards a packet. Assuming the router works correctly, this next rule will only allow echo request and echo response messages to and from nodes on the local Ethernet segment. Using the hop limit value, we can allow certain types of traffic only from other nodes connected to the same router.

You can adjust the rate to be anything that you think is reasonable. If you only want to use echo request and echo response with nearby nodes, the hl (hop limit) module can be useful. These rules restrict echo request and reply to packets that have 255 as the hop limit:

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-eq 255 -j ACCEPT

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m limit --limit 900/min -m hl --hl-lt 255 -j DROP

ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 129 -m limit --limit 900/min -m hl --hl-let 255 -j DROP

By default, the Windows Firewall in Vista (and Server 2008) drops inbound packets and allows outbound packets. Let's work on filtering rules for the "Traffic for Which a Policy Should Be Defined" section of RFC 4890.

Use the following command to block router redirects (type 137):

netsh advfirewall firewall add rule name "block icmpv6 type 137" dir=in action=block protocol=icmpv6:137,any

Although blocking router redirects on untrusted networks is probably a good idea, the default state of the Vista firewall doesn't explicitly allow that ICMPv6 type inbound, so we haven't done anything. Let's try something a little more advanced. This next rule allows ICMPv6 redirect messages, but only if the computer is using the "domain" profile. We could get similar functionality with ip6tables, but only if Networkmanager scripts are used (we might talk about this in a future blog entry).

netsh advfirewall firewall add rule name "allow icmpv6 type 137 for the domain profile" dir=in action=allow protocol=icmpv6:137,any profile=domain

This rule implies that the computer is logged into a domain controller and has authenticated via Active Directory. Microsoft offers more information about the profiles.

Administrators may worry about bandwidth on some links more than others. The following rule allows inbound echo requests on wired connections only:

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any inerfacetype=lan

The Vista firewall includes the ability to allow (or deny) connections that are authenticated by IPsec. The security= directive can also require that connections are authenticated (authenticate) or authenticated and encrypted (authenc):

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any security=authenticate

netsh advfirewall firewall add rule name "allow icmpv6 type 128 when wired" dir=in action=allow protocol=icmpv6:128,any security=authenc

If you'd like to learn more about configuring the Vista firewall by using netsh commands, see the Microsoft Technet article "Netsh Commands for Windows Firewall with Advanced Security." The ip6tables documentation is in their man page.

If you're interested in ip6tables rules, we have a more complete list that includes rules not mentioned in this blog entry.

Reported Vulnerability in CERT Secure Coding Standards Website

2008-10-29T16:04:00Z

Hi, it's Will. Recently, a blog author reported that the CERT^® Secure Coding Standards website, which runs on Atlassian Confluence, contained a SQL injection vulnerability. After analyzing the report and discussing it with the Confluence vendor, we have concluded that the behavior described is not a vulnerability.

]]> On October 24, 2008, rvdh posted an entry on the 0x000000 blog that implied that the CERT Secure Coding website contained a SQL injection vulnerability. This website runs Atlassian Confluence, which is used by multiple organizations. If there were a publicly known SQL injection vulnerability in the Confluence software, it would have a pretty widespread effect on these organizations, CERT included. This prompted us to investigate the issue.

When performing a specific query to the Confluence software, an error and detailed stack trace is displayed to the user. From this error, rvdh draws the following conclusion: "^ Oops, besides this hideous blob of intelligence it also let us modify the SQL query. Finally something really interesing to discuss at those cocktail parties or is it?"

It is true that the stack trace is ugly, but that's about as far as the flaw goes. The malformed query does not make it to the SQL part of the Confluence code. If you look at the stack trace, you will notice that the error is generated by the QueryParser component of Apache Lucene. It's not clear where rvdh draws the conclusion that you can modify the SQL query. Sure, you have control over what values might be used to perform the search, but that is expected.

Here is the response from Atlassian, which is the vendor that produces Confluence:

The proposed "attack" supplies the server with an invalid search query that causes Confluence to display an error message. This is a bug only insofar as we don't present a better error message.
The query in question is performed against the Lucene index. It is never passed anywhere near SQL, so it can not be used for SQL injection Lucene queries are read-only, so it is impossible for a search query to modify the index in any way, however constructed
Lucene queries are constructed programatically, so there is no way for the user-supplied portion of the query can effect the query's security constraints and view data that could not otherwise be found in a search by that user
As an application that is mostly used in intranets, Confluence's default error page is very wordy. Customers who want to limit the amount of information leaked during system errors can do so by editing their 500.jsp file to remove the backtrace and error information.
Even if this were an SQL query, Confluence uses standard prepared-statement-style parameter insertion to generate SQL queries. As such it is highly resistant to SQL injection attacks.
For more information about Confluence security practices, and a list of all recorded Confluence security advisories, please see this page:

http://confluence.atlassian.com/display/DOC/Confluence+Security

Ping sweeping in IPv6

2008-09-12T19:06:00Z

Hello, its Ryan. We've noticed a misconception about IPv6 that is popular on the internet: that IPv6 addresses are hard to ping sweep because there are so many possible addresses. Ping sweeping can lead to port scanning, so this misconception is viewed as a security feature. In this post, I'll prove that, while it won't work across the internet, ping sweeping on the local network is easier in IPv6 than in IPv4.

]]> Before we go further, if you don't know what IPv6 is, read this Wikipedia entry. Essentially, IPv6 is a new protocol that is a lot like the currently deployed IPv4, but it has many more addresses (about 2^128 total). It is so much like IPv4 that a lot of network gear supports IPv6 without any modifications. Most newer operating systems have native IPv6 support, and many prefer IPv6 connections over IPv4 ones.

On our IPv6 test network, we are running a few Linux machines and an OS X laptop. On one of the Linux machines, we run the following command:

ping6 -I eth0 ff02::1

And, on this machine, the neighbor cache fills up with all the link local addresses of the other computers connected to the node. Linux systems with iproute2 can use command

ip neighbor

to show the neighor cache. Folks on Windows Vista and Server 2008 can use the netsh command

netsh interface ipv6 show neighbors

What just happened?

Well, we sent an ICMPv6 echo request (type 128) message to the all-nodes multicast address. All the nodes that were listening sent back the ICMPv6 echo reply (type 129) message. When we received these messages, their link-local (and MAC) addresses were added to our neighbor cache. eth0 is the interface connected to the network (the -I flag is needed when pinging the multicast address).

Ok, so that was fun--we just created a list of all the link layer addresses on our Ethernet segment. The next exercise is even more fun. Run this command:

ping6 -B -I eth0 -I [global IPv6 address attached to eth0] ff02::1

Now check the neighbor cache. It will show the global IPv6 (the equivalent of a public IPv4) address. We just discovered the global IPv6 addresses of the hosts on our network.

These commands won't work across the internet because, in general, multicast isn't supported across the web. They also won't work with hosts that filter ICMPv6 types 128 and 129 (which is not compliant with RFC 4980 section 4.4.1). However, it is not possible to block all ICMPv6 types, and an analysis of restrictive host-based firewalls will likely show that some multicast ICMPv6 traffic is allowed.

So what can you do about this problem? Not that much, and the truth is, it isn't really a problem. Things are working exactly as they should, and security effort is usually better spent making sure hosts are secure, not obscure.

Many network managers think their networks don't support IPv6 because it hasn't been officially deployed. Most networking gear we tested that works at layer 2 seems to pass IPv6 packets with no problem. Flat networks will probably support IPv6 just fine. Almost all popular operating systems support and prefer IPv6.

So, what's to prevent an attacker from starting a stateless auto-config server (a way to send router advertisements), passing out IPv6 addresses, and possibly conducting ping sweeps on your network? Probably nothing. If you purchased network security equipment that protects you from IPv4-based attacks, this doesn't need mean that it's broken. IPv6 is a new protocol, and you'll probably need to deploy new equipment, upgrade old equipment, and/or notify users of the risks of running IPv6 on your network. An applicable analogy is that its like purchasing a Blu-Ray disc for a movie that you already own on DVD.

If you'd like more information about how this works, email us at cert@cert.org with INFO#498112 in the subject line. We have some other blog posts about IPv6 coming soon, and we'd like to know answers to these questions:

Do you deploy commercial or open source network switches or IDS systems that provide robust IPv6 support?
If you ran these ping6 commands on your network, how effective were they?
Are your hosts blocking ICMPv6? Do you plan to keep them with that configuration?

Carpet Bombing and Directory Poisoning

2008-09-04T19:50:08Z

Hey, it's Will. Earlier this year, details about "carpet bombing" attacks were released. Apple addressed the issue by prompting users before downloading files, but recent news indicates that Google Chrome, which is based on Apple's WebKit code, is also vulnerable to the same type of attack. However, some people seem to be missing an aspect of the attack that affects all web browsers.

]]> When loading a DLL, Microsoft Windows looks for the DLL in a certain sequence of directories. The first match for the file name wins. In most cases, Windows will first look for a DLL in the same location as the executable. This behavior is what allows the Apple Safari "carpet bombing" vulnerability to work. If an attacker can place code in a directory that gets searched before Windows finds the "real" DLL, the attacker's code will be executed.

Consider the following scenario: Suppose that you use a web browser to download files, and you have some directory where you put your downloaded files. As time goes on, that directory gets filled with items that you've downloaded. Occasionally, you may open one of the trusted programs that you've explicitly downloaded and run it from your browser's download manager or from Windows Explorer.

If this scenario seems plausible, you may have inadvertently executed malicious code! This risk is even greater if you use a web browser that saves files to your computer without prompting, such as Google Chrome or an older version of Apple Safari for Windows. It's important to note, though, that any web browser or other application is at risk here, too, because the DLL search order behavior is a feature of Microsoft Windows.

What can you do to protect yourself from this kind of attack? For starters, make sure that your web browser is configured to prompt you before downloading a file. For example, Google Chrome has a preference called "Ask where to save each file before downloading." Configuring your web browser to prompt you before downloading a file can help prevent a directory from being "poisoned" without your knowledge. The most effective protection, however, is to move a file to a trusted (i.e., empty) directory before executing it. Before running a program in Microsoft Windows, it is not enough to verify that you trust the program itself. You must also trust the directory from which the application is launched. A cluttered download directory is not trustworthy.

Windows Vista does not appear to be vulnerable to directory poisoning. In my testing, Vista seems to give DLL search order priority to the system directory rather than to the executable's current directory.

Safely Using Package Managers

2008-07-10T13:48:04Z

Hi, it's Ryan. Package managers partially automate the process of installing and removing software packages. Most package managers use cryptographic signatures to verify the integrity of packages. In the article Attacks on Package Managers, the authors describe how an attacker can abuse package managers that use digital signatures.

]]> Most operating systems have package managers, but UNIX-like systems use them extensively to manage packages on an installed system. Some examples of system-wide package managers (we're purposely avoiding application-specific package managers in this post) are APT, Portage, and YUM. There are a lot more, though—Wikipedia has a partial list of others.

Many of these package managers use cryptographic signatures to verify the integrity of packages. The Debian Wiki describes how APT uses GPG to check packages, and other package managers behave in a similar way.

What problems can the attacker cause by gaining control of a mirror? Completely shutting down the mirror server would be easy for users to notice. A more subtle attack would be to distribute packages that are signed but still contain vulnerabilities. How can a package be both signed and vulnerable? Well, before CVE-2008-0166 was discovered, OpenSSL (OpenSSL versions 0.9.8c-1 to 0.9.8g-9 on Debian-based systems to be precise) did not have any publicly known vulnerabilities. After discovery, OpenSSL had well-known problems, and, until they were updated, SSH servers (OpenSSH uses OpenSSL) were vulnerable. However, the vulnerable version is still a valid signed package. Assuming that a user is obtaining security updates from a third-party mirror, that mirror could pass the user signed packages with known vulnerabilities.

Before going any further, it's worth pointing out that this problem isn't limited to open-source vendors. Any software that gets updates via the internet (just about all software) could be affected. However, exploitation is much more difficult when the software vendor directly controls the mirrors--before attacking clients, an attacker needs to locate and take control of the mirror. Many open-source projects make it simple for third parties to become mirrors.

So, we've talked about the problem and why it is somewhat of a concern for vendors that don't directly control their mirrors. As far as we can tell, no mirror site has intentionally given clients packages with known vulnerabilities and then exploited those vulnerabilities. Furthermore, there are several things mirror users and administrators can do to protect themselves:

Administrators can avoid using third-party repositories by running locally hosted mirrors, setting up caches, or getting packages from a trusted source. It is important to note that exploits can be created rapidly, so even a small delay in getting fixed software can be problematic.
When third-party repositories need to be enabled, users should select their respositories carefully. How long has the mirror been around? Is it up to date? Is it easier to get the package from another source (such as the developer's home page)? Does the operating system vendor track the repo?

Projects use mirrors to reduce bandwidth costs and provide redundancy. How can software maintainers offer secure mirrors that aren't slow and unstable? Some commercial Linux distributions offer high-speed direct downloads from trusted sources. Another potential solution to this problem is P2P technology. If widely used, programs like DebTorrent may allow official repositories to distribute metadata and tracker information while decreasing bandwidth costs.

The issues we've talked about (mirror distribution, software integrity) are a subset of the larger problem of obtaining, installing, and managing trusted software. The importance of obtaining verified, trusted packages needs to managed according to your security policy.

Thanks to Justin Cappos and Justin Samuel for providing us information about these issues. A special thanks to all the vendors who gave us feedback.

If you send us mail, we are tracking these issues as VU#230187.

ActiveX Vulnerability Discovery at the CERT/CC

2008-07-03T13:55:01Z

Hi, it's Will. Anybody who has been keeping an eye on the US-CERT Vulnerability Notes has probably noticed that I've published a lot of ActiveX vulnerabilities. So it should be no surprise to learn that we have been testing ActiveX controls and discovering vulnerabilities in the process.

]]> Vulnerability Detection in ActiveX Controls through Automated Fuzz Testing. This paper describes the various attack surfaces of ActiveX controls, the techniques used to test those attack surfaces, and also some results obtained by testing a large number of downloaded ActiveX controls. It may also give some insight into why the Securing Your Web Browser document suggests disabling ActiveX in the Internet Zone of Internet Explorer.

Signed Java Applet Security: Worse than ActiveX?

2008-06-03T18:38:12Z

Hi, it's Will again. ActiveX vulnerabilities seem to be getting a lot of attention lately. However, Java applets are also a concern. ]]> sandbox in your web browser. This model prevents a Java applet from accessing sensitive resources, such as your file system or registry. So, barring vulnerabilities in the Java Virtual Machine (JVM), Java applets should not have the ability to do anything malicious on your system. That was the case with the JDK 1.0 security model.

Starting with version 1.1, Java included support for signed applets. These applets, which can run in your web browser as the result of viewing a web page, are not limited by any sandbox and can do just about anything that native code can. In other words, a signed Java applet should be treated the same as an EXE file on Windows.

When a web page attempts to run a signed Java applet, the Java Runtime Environment (JRE) will prompt the user before executing the code. When a Java applet without a trusted certificate is started, the JRE will, by default, still allow the user to execute the code. Some versions of JRE may warn the user that the digital signature cannot be verified. For example, the following dialog is presented when the JRE encounters an applet with an untrusted signature, such as a self-signed applet:

If the Java applet is signed with a trusted certificate, the user will still be prompted. However, the option to Always trust content from this publisher is enabled by default. This means that if you run a signed Java applet from one particular vendor, you will trust all Java applets from that vendor by default, regardless of the site that is hosting them. The following dialog is presented when a Java applet with a valid signature is started. Note the default option of trusting all applets signed by that publisher.

Now let's consider the vulnerability remediation steps regarding a signed Java applet. With ActiveX, Microsoft has the ability to deploy a kill bit for a control that is vulnerable. Everybody who is set up for automatic updates from Microsoft will receive the kill bit, which prevents the control from being used in Internet Explorer. But what happens if a vulnerable signed Java applet is discovered? There is no Java analogy to the ActiveX kill bit. An attacker can host a copy of the Java applet on his or her own web site, and that applet will still have a valid digital signature. Keep in mind that just like with ActiveX, a digital signature gives no indication of the safety of running the code. It can only indicate that the code was actually written by the organization that is listed on the signature. And even then, the user has to trust that the Certification Authority (CA) did due diligence in verifying the identity of the code signer.

This lack of remediation options is why I believe that from a security perspective, signed Java is about on par with ActiveX... circa 1996. Internet Explorer started supporting the kill bit and blocking ActiveX controls with invalid signatures in version 4, which was released in 1997.

So how can you protect yourself against malicious or vulnerable signed Java applets? The easiest way is to disable Java, as explained in our Securing Your Web Browser document. If you need to use Java, there are other options that can restrict the use of signed Java applets:

The option to Allow user to grant permissions to signed content can be disabled. With this option disabled, unsigned applets will still run in the Java sandbox. But any signed applet will be denied.
The option to Allow user to grant permissions to content from an untrusted authority can be disabled. Unsigned applets will still run, as with the above option. Applets that are signed with a trusted certificate authority can also run. But applets that have an untrusted signature, such as a self-signed applet, will be blocked.
The options Check publisher certificate for revocation and Enable online certificate validation should be enabled. These options will enable further validation of Java certificates. Note that these options are not enabled by default.

The following dialog shows the relevant options. These options are available in the Java Control Panel item for Windows, in the Advanced tab, listed under Security. Other platforms may require different steps.

From the user awareness point of view, if you are ever presented with a dialog that is requesting permission to run a signed Java applet, keep in mind that the code may be malicious. If you do not trust both the Publisher and the From fields in the dialog, you should not run the application.

Is Your Adobe Flash Player Updated?

2008-05-29T22:42:15Z

Hey, it's Will. As you may already be aware, there is active exploitation of a vulnerability in Adobe Flash. So, it's a good idea to make sure that you have the latest version of Flash Player, which, at the time of this writing, is 9.0.124.0. Even if you think that you are up to date, can you be sure? ]]>
It is important to realize that a system may contain several instances of the Adobe Flash Player. The Adobe Flash Player plug-in installer for Windows will install only the Netscape-style plug-in for Flash, which is used by Mozilla Firefox, Opera, and other browsers that support plug-ins. The Adobe Flash Player ActiveX installer for Windows will install only the ActiveX version of Flash, which is used by Internet Explorer and other programs that use Internet Explorer components.

The situation that someone may run into is that the plug-in version of Flash may be completely up to date, but the ActiveX version is not, or vice-versa.

All Microsoft Windows systems should run the the ActiveX installer. If you have any browser other than Internet Explorer, also run the plug-in installer. Alternatively, visit the Get Flash Player page with every browser on your system to install the appropriate Flash Player versions.

Another cause for confusion is that Firefox allows plug-ins to be installed either system-wide or in a specific user's profile. As a result, a Flash plug-in that was installed in one manner may not be updated properly if the new version of Flash is installed in a different manner. Other browsers may have similar issues.

At the very least, make sure that you have attempted to upgrade to the latest version of Adobe Flash. But to make sure that you are protected, it would be wise to investigate whether your system has multiple versions of Adobe Flash Player, and update each of those accordingly.

Who has my cookies?

2008-05-15T19:21:16Z

Hi, Ryan Giobbi from the Vulnerability Analysis team making this post. The CERT/CC has been tracking cross-site scripting vulnerabilities for a long time, and the actual vulnerabilities haven't changed much over the years. However, some technology that was developed to make life easier can actually be exploited to expand the impact of a cross-site scripting attack. ]]>
Here's some background information on how some websites do authentication: many websites set cookies to identify, track, and authenticate users. Online services that use cookies for authentication are constrained by the browser's same origin policy. For example, the cookie set by http://mail.example.com cannot access the cookie set by http://www.example.com.

To support single sign-on, web applications may set one authentication cookie and structure their URLs to allow multiple sites to access the cookie. Under this architecture, a single XSS (cross-site scripting) vulnerability could affect numerous applications.

A few weeks ago, we saw a report of an XSS vulnerability in Google Spreadsheets over on Billy (BK) Rios's blog. These type of vulnerabilities are not rare, but this one was interesting because of its impact—Google uses single sign-on to manage access to many of their hosted applications.

Web application vendors can (and often do) plug XSS holes in their services to prevent exploitation of these types of vulnerabilities—but what can users do to protect themselves? The Securing Your Web Browser document has some good tips, and users should also consider how often they are logged into web applications. Certain XSS attacks (such as ones that steal authentication cookies) only work if the user is logged into the web application and has an authentication cookie on their system. To limit exposure to these types of vulnerabilities, users can uncheck "remember me on this computer" options on web-application login forms and can regularly delete cookies.

The Dangers of Windows AutoRun

2008-04-24T23:12:00Z

Hi, this is Will Dormann of the CERT/CC Vulnerability Analysis team. A few months ago, reports of infected digital picture frames hit the media. I was curious about how the malicious code was being executed, so I began investigating the Microsoft AutoRun and AutoPlay features.

]]> AutoRun, which was introduced with Windows 95, has two primary behaviors:

For certain device types, such as CD-ROM drives, Windows will automatically execute the program that is specified in the Autorun.inf file when the device is connected or when media is inserted. The security impact of this feature is that somebody with physical access to a Windows computer can run malicious code by inserting a CD-ROM into the drive. But we already know that physical access to a computer can give an attacker the ability to do just about anything, right?
When a drive icon is clicked in Windows Explorer, Windows will execute the program specified in the Autorun.inf file. In this case, user interaction is required for the code to execute. However, the AutoRun behavior can be unexpected, as it is common to believe that clicking the drive icon will display the contents of the drive, rather than executing code.

In the process of investigating AutoRun behavior, I noticed two interesting things:

With Windows Vista, the NoDriveTypeAutoRun registry value actually has the opposite behavior than what Windows has documented. In other words, if you think that you have protected yourself by restricting AutoRun with this registry value, you have actually put yourself at additional risk. We have published details about this issue as US-CERT Vulnerability Note VU#889747. The end result here is that a user may inadvertently execute code by clicking on the icon for a device, such as a USB thumb drive.
Although the documentation for NoDriveTypeAutoRun indicates that Windows will not use AutoRun features on USB mass storage devices, this does not necessarily mean that users can safely plug any USB device into their system. For example, a system will recognize Sandisk U3 USB devices as both a CD-ROM device and a USB mass-storage device. Considering that an attacker can easily modify the CD-ROM contents of a U3 device, you now have a way for an attacker to execute code of their choice on a Windows system by simply plugging in a small USB device. No other user interaction is required.

The information about malicious use of U3 drives is not particularly new. But how many systems have AutoRun disabled? One aspect that makes the problem confusing is that it is not obvious how to disable AutoRun precisely and effectively. VU#889747 originally listed several steps that appeared to be effective in my testing, but they also had the adverse effect of disabling MCN messages, which can prevent Windows from detecting when a CD-ROM or DVD is changed.

One of our readers has provided us with a workaround that disables AutoRun closest to the source, which is the Autorun.inf file itself. By importing the following registry key, the Autorun.inf file will no longer be used to determine AutoRun and AutoPlay actions:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]

@="@SYS:DoesNotExist"

This setting appears to disable AutoRun behaviors without causing other negative side-effects. More details about this workaround are available in Nick Brown's blog entry Memory stick worms.

Update (November 21, 2008):

Microsoft Windows may cache AutoRun information from connected devices. The impact of this feature is that even after disabling AutoRun as described above, you may still experience AutoRun behaviors for devices (USB drives, network shares, etc.) that have been connected to the computer in the past. For this reason, we also recommend removing this cache by deleting the MountPoints2 registry key for each user:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Vulnerability Analysis at the CERT/CC

2008-04-17T15:51:00Z

Hi, this is Art Manion, the Vulnerability Analysis team lead at the CERT Coordination Center (CERT/CC). For our first blog entry, I'd like to briefly explain our efforts to reduce software vulnerabilities.

]]> One approach is to remove known vulnerabilities from deployed software (from another angle, this means reducing the amount of time that software contains a particular vulnerability). We consider this "traditional" vulnerability analysis and coordination:

find out about a vulnerability, whether from a public source, private report, or internal discovery
analyze the vulnerability and consider threat scenarios
identify and securely contact vendors that may be affected
coordinate disclosure to private and public audiences

Summarized neatly, this all sounds easy enough. In practice, though, things aren't so simple:

There are a lot of vulnerabilities. Which ones are the most severe? What do I consider severe? What do you consider severe?
How should I expend effort to get the most out of my limited vulnerability analysis and response resources?
Which vendors produce, maintain, or distribute the vulnerable software? How do I contact those vendors and communicate securely with them?
If I find a vulnerability, how do I report it, and are there any risks associated with reporting?
Which disclosure practice do I follow? How much and what kind of information should go into an advisory?

The CERT/CC works closely with US-CERT (part of the Department of Homeland Security) on vulnerability analysis and coordination. For us, public vulnerability disclosure typically results in a US-CERT Technical Alert or Vulnerability Note.

Experience suggests that we will be dealing with vulnerabilities for years to come. Responding to vulnerability reports, as either a software producer or a consumer, should not be treated as an emergency or "one-off" event. Both software producers (vendors) and consumers (users) should develop vulnerability management capabilities that are built into normal business processes. For vendors, vulnerability management includes advertising ways to receive vulnerability reports, coordinating among internal business units and with external parties, being familiar with coordination and disclosure practices, and delivering vulnerability information and fixed software. For users, vulnerability management involves the following: awareness of new vulnerability information, inventory and patch management, risk assessment, configuration and change control, and consideration of procurement and support contract language.

Thinking about the subjective question about the severity of a given vulnerability has led us to research ways to make better decisions about how to respond to vulnerabilities. But that is a story for another entry.

What I've described above is focused on responding to vulnerabilities in already deployed software. We are also taking a more proactive approach to reduce the number of newly introduced vulnerabilities. This effort, which falls under the CERT Secure Coding Initiative, involves training developers, improving source-code analysis tools, and developing secure coding standards.

An administrative note—our blog is not going to have comments enabled, at least for now. If you'd like to provide feedback, please send us email using the link in the right sidebar. We'll consider updating entries based on feedback we receive.