Entries Tagged "vulnerabilities"

Page 40 of 45

DHS Funding Open Source Security

From eWeek:

The U.S. government’s Department of Homeland Security plans to spend $1.24 million over three years to fund an ambitious software auditing project aimed at beefing up the security and reliability of several widely deployed open-source products.

The grant, called the “Vulnerability Discovery and Remediation Open Source Hardening Project,” is part of a broad federal initiative to perform daily security audits of approximately 40 open-source software packages, including Linux, Apache, MySQL and Sendmail.

The plan is to use source code analysis technology from San Francisco-based Coverity Inc. to pinpoint and correct security vulnerabilities and other potentially dangerous defects in key open-source packages.

Software engineers at Stanford University will manage the project and maintain a publicly available database of bugs and defects.

Anti-virus vendor Symantec Corp. is providing guidance as to where security gaps might be in certain open-source projects.

I think this is a great use of public funds. One of the limitations of open-source development is that it’s hard to fund tools like Coverity. And this kind of thing improves security for a lot of different organizations against a wide variety of threats. And it increases competition with Microsoft, which will force them to improve their OS as well. Everybody wins.

What’s affected?

In addition to Linux, Apache, MySQL and Sendmail, the project will also pore over the code bases for FreeBSD, Mozilla, PostgreSQL and the GTK (GIMP Tool Kit) library.

And from ZDNet:

The list of open-source projects that Stanford and Coverity plan to check for security bugs includes Apache, BIND, Ethereal, KDE, Linux, Firefox, FreeBSD, OpenBSD, OpenSSL and MySQL, Coverity said.

Posted on January 17, 2006 at 1:04 PMView Comments

Bug Bounties Are Not Security

Paying people rewards for finding security flaws is not the same as hiring your own analysts and testers. It’s a reasonable addition to a software security program, but no substitute.

I’ve said this before, but Moshe Yudkowsky said it better:

Here’s an outsourcing idea: get rid of your fleet of delivery trucks, toss your packages out into the street, and offer a reward to anyone who successfully delivers a package. Sound like a good idea, or a recipe for disaster?

Red Herring offers an article about the bounties that some software companies offer for bugs. That is, if you’re an independent researcher and you find a bug in their software, some companies will offer you a cash bonus when you report the bug.

As the article notes, “in a free market everything has value,” and therefore information that a bug exists should logically result in some sort of market. However, I think it’s misleading to call this practice “outsourcing” of security, any more than calling the practice of tossing packages into the street a “delivery service.” Paying someone to tell you about a bug may or may not be a good business practice, but that practice alone certainly does not constitute a complete security policy.

Posted on December 27, 2005 at 7:46 AMView Comments

Internet Explorer Sucks

This study is from August, but I missed it. The researchers tracked three browsers (MSIE, Firefox, Opera) in 2004 and counted which days they were “known unsafe.” Their definition of “known unsafe”: a remotely exploitable security vulnerability had been publicly announced and no patch was yet available.

MSIE was 98% unsafe. There were only 7 days in 2004 without an unpatched publicly disclosed security hole.

Firefox was 15% unsafe. There were 56 days with an unpatched publicly disclosed security hole. 30 of those days were a Mac hole that only affected Mac users. Windows Firefox was 7% unsafe.

Opera was 17% unsafe: 65 days. That number is accidentally a little better than it should be, as two of the upatched periods happened to overlap.

This underestimates the risk, because it doesn’t count vulnerabilities known to the bad guys but not publicly disclosed (and it’s foolish to think that such things don’t exist). So the “98% unsafe” figure for MSIE is generous, and the situation might be even worse.

Wow.

Posted on December 26, 2005 at 6:27 AMView Comments

Electronic Shackles and Telephone Communications

The article is in Hebrew, but the security story is funny in any language.

It’s about a prisoner who was forced to wear an electronic shackle to monitor that he did not violate his home arrest. The shackle is pretty simple: if the suspect leaves the defined detention area, the electronic shackle signals through the telephone line to the local police.

How do you defeat a system such as this? Just stop paying your phone bill and wait for the phone company to shut off service.

Posted on December 21, 2005 at 12:03 PMView Comments

Are Port Scans Precursors to Attack?

Interesting research:

Port scans may not be a precursor to hacking efforts, according to conventional wisdom, reports the University of Maryland’s engineering school.

An analysis of quantitative attack data gathered by the university over a two-month period showed that port scans precede attacks only about five percent of the time, said Michel Cukier, a professor in the Centre for Risk and Reliability. In fact, more than half of all attacks aren’t preceded by a scan of any kind, Cukier said.

I agree with Ullrich, who said that the analysis seems too simplistic:

Johannes Ullrich, chief technology officer at the SANS Institute ‘s Internet Storm Center, said that while the design and development of the testbed used for the research appears to be valid, the analysis is too simplistic.

Rather than counting the number of packets in a connection, it’s far more important to look at the content when classifying a connection as a port scan or an attack, Ullrich said.

Often, attacks such as the SQL Slammer worm, which hit in 2003, can be as small as one data packet, he said. A lot of the automated attacks that take place combine port and vulnerability scans and exploit code, according to Ullrich.

As a result, much of what researchers counted as port scans may have actually been attacks, said Ullrich, whose Bethesda, Md.-based organization provides Internet threat-monitoring services.

Posted on December 15, 2005 at 6:38 AMView Comments

Weakest Link Security

Funny story:

At the airport where this pilot fish works, security has gotten a lot more attention since 9/11. “All the security doors that connect the concourses to office spaces and alleyways for service personnel needed an immediate upgrade,” says fish. “It seems that the use of a security badge was no longer adequate protection.

“So over the course of about a month, more than 50 doors were upgraded to require three-way protection. To open the door, a user needed to present a security badge (something you possess), a numeric code (something you know) and a biometric thumb scan (something you are).

“Present all three, and the door beeps and lets you in.”

One by one, the doors are brought online. The technology works, and everything looks fine—until fish decides to test the obvious.

After all, the average member of the public isn’t likely to forge a security badge, guess a multidigit number and fake a thumb scan. “But what happens if you just turn the handle without any of the above?” asks fish. “Would it set off alarms or call security?

“It turns out that if you turn the handle, the door opens.

“Despite the addition of all that technology and security on every single door, nobody bothered to check that the doors were set to lock by default.”

Remember, security is only as strong as the weakest link.

Posted on December 14, 2005 at 11:59 AMView Comments

GAO Report on Electronic Voting

The full report, dated September 2005, is 107-pages long. Here’s the “Results in Brief” section:

While electronic voting systems hold promise for a more accurate and efficient election process, numerous entities have raised concerns about their security and reliability, citing instances of weak security controls, system design flaws, inadequate system version control, inadequate security testing, incorrect system configuration, poor security management, and vague or incomplete voting system standards, among other issues. For example, studies found (1) some electronic voting systems did not encrypt cast ballots or system audit logs, and it was possible to alter both without being detected; (2) it was possible to alter the files that define how a ballot looks and works so that the votes for one candidate could be recorded for a different candidate; and (3) vendors installed uncertified versions of voting system software at the local level. It is important to note that many of the reported concerns were drawn from specific system makes and models or from a specific jurisdiction’s election, and that there is a lack of consensus among election officials and other experts on the pervasiveness of the concerns. Nevertheless, some of these concerns were reported to have caused local problems in federal elections—resulting in the loss or miscount of votes—and therefore merit attention.

Federal organizations and nongovernmental groups have issued recommended practices and guidance for improving the election process, including electronic voting systems, as well as general practices for the security and reliability of information systems. For example, in mid-2004, EAC issued a compendium of practices recommended by election experts, including state and local election officials. This compendium includes approaches for making voting processes more secure and reliable through, for example, risk analysis of the voting process, poll worker security training, and chain of custody controls for election day operations, along with practices that are specific to ensuring the security and reliability of different types of electronic voting systems. As another example, in July 2004, the California Institute of Technology and the Massachusetts Institute of Technology issued a report containing recommendations pertaining to testing equipment, retaining audit logs, and physically securing voting systems. In addition to such election-specific practices, numerous recommended practices are available that can be applied to any information system. For instance, we, NIST, and others have issued guidance that emphasizes the importance of incorporating security and reliability into the life cycle of information systems through practices related to security planning and management, risk management, and procurement. The recommended practices in these election-specific and information technology (IT) focused documents provide valuable guidance that, if implemented effectively, should help improve the security and reliability of voting systems.

Since the passage of HAVA in 2002, the federal government has begun a range of actions that are expected to improve the security and reliability of electronic voting systems. Specifically, after beginning operations in January 2004, EAC has led efforts to (1) draft changes to the existing federal voluntary standards for voting systems, including provisions related to security and reliability, (2) develop a process for certifying, decertifying, and recertifying voting systems, (3) establish a program to accredit the national independent testing laboratories that test electronic voting systems against the federal voluntary standards, and (4) develop a software library and clearinghouse for information on state and local elections and systems. However, these actions are unlikely to have a significant effect in the 2006 federal election cycle because the changes to the voluntary standards have not yet been completed, the system certification and laboratory accreditation programs are still in development, and the software library has not been updated or improved since the 2004 elections. Further, EAC has not defined tasks, processes, and time frames for completing these activities. As a result, it is unclear when the results will be available to assist state and local election officials. In addition to the federal government’s activities, other organizations have actions under way that are intended to improve the security and reliability of electronic voting systems. These actions include developing and obtaining international acceptance for voting system standards, developing voting system software in an open source environment (i.e., not proprietary to any particular company), and cataloging and analyzing reported problems with electronic voting systems.

To improve the security and reliability of electronic voting systems, we are recommending that EAC establish tasks, processes, and time frames for improving the federal voluntary voting system standards, testing capabilities, and management support available to state and local election officials.

EAC and NIST provided written comments on a draft of this report (see apps. V and VI). EAC commissioners agreed with our recommendations and stated that actions on each are either under way or intended. NIST’s director agreed with the report’s conclusions. In addition to their comments on our recommendations, EAC commissioners expressed three concerns with our use of reports produced by others to identify issues with the security and reliability of electronic voting systems. Specifically, EAC sought (1) additional clarification on our sources, (2) context on the extent to which voting system problems are systemic, and (3) substantiation of claims in the reports issued by others. To address these concerns, we provided additional clarification of sources where applicable. Further, we note throughout our report that many issues involved specific system makes and models or circumstances in the elections of specific jurisdictions. We also note that there is a lack of consensus on the pervasiveness of the problems, due in part to a lack of comprehensive information on what system makes and models are used in jurisdictions throughout the country. Additionally, while our work focused on identifying and grouping problems and vulnerabilities identified in issued reports and studies, where appropriate and feasible, we sought additional context, clarification, and corroboration from experts, including election officials, security experts, and key reports’ authors. EAC commissioners also expressed concern that we focus too much on the commission, and noted that it is one of many entities with a role in improving the security and reliability of voting systems. While we agree that EAC is one of many entities with responsibilities for improving the security and reliability of voting systems, we believe that our focus on EAC is appropriate, given its leadership role in defining voting system standards, in establishing programs both to accredit laboratories and to certify voting systems, and in acting as a clearinghouse for improvement efforts across the nation. EAC and NIST officials also provided detailed technical corrections, which we incorporated throughout the report as appropriate.

Posted on December 2, 2005 at 3:08 PMView Comments

Possible Net Objects Fusion 9 Vulnerability

I regularly get anonymous e-mail from people exposing software vulnerabilities. This one looks interesting.

Beta testers have discovered a serious security flaw that exposes a site created using Net Objects Fusion 9 (NOF9) that has the potential to expose an entire site to hacking, including passwords and log in info for that site. The vulnerability exists for any website published using versioning (that is, all sites using nPower).

The vulnerability is easy to exploit. In your browser enter:
http://domain.com/_versioning_repository_/rollbacklog.xml

Now enter:
http://domain.com/_versioning_repository_/n.zip, where n is the number you got from rollback.xml.

Then, open Fusion and create a new site from the d/l’ed template. Edit and republish.

This means that anyone can edit a NOF9 site and get any usernames and passwords involved in it. Every site using versioning in NOF9 is exposing their site.

Website Pros has refused to fix the hole. The only concession that they have made is to put a warning in the publishing dialog box telling the user to “Please make sure your profiles repository are [sic] stored in a secure area of your remote server.”

I don’t use NOF9, and I haven’t tested this vulnerability. Can someone do so and get back to me? And if it is a real problem, spread the word. I don’t know yet if Website Pros prefers to pay lawyers to suppress information rather than pay developers to fix software vulnerabilities.

Posted on November 21, 2005 at 12:31 PMView Comments

Cold War Software Bugs

Here’s a report that the CIA slipped software bugs to the Soviets in the 1980s:

In January 1982, President Ronald Reagan approved a CIA plan to sabotage the economy of the Soviet Union through covert transfers of technology that contained hidden malfunctions, including software that later triggered a huge explosion in a Siberian natural gas pipeline, according to a new memoir by a Reagan White House official.

A CIA article from 1996 also describes this.

EDITED TO ADD (11/14): Marcus Ranum wrote about this.

Posted on November 14, 2005 at 8:04 AMView Comments

1 38 39 40 41 42 45

Sidebar photo of Bruce Schneier by Joe MacInnis.