ZDNet UK


Skip to Main Content

ZDNet.co.uk - Winner of Best Business Website 2007
  1. Home
  2. News
  3. Blogs
  4. Reviews
  5. Prices
  6. Resources
  7. Community
  8. My ZDNet

 

ZDNet UK RSS Feeds


IT Jobs

Security threats Toolkit

CA flaws opens users up to DoS attacks

Dawn Kawamoto CNET News.com

Published: 07 Apr 2005 09:40 BST

  • Email
  • Trackback
  • Clip Link
  • Print friendly
  • Post Comment

A flaw has been discovered in Computer Associates' eTrust Intrusion Detection System that could make the system vulnerable to denial-of-service attacks, according to an advisory by security research company iDefense.

The flaw enables a writer of malicious code to disable CA's eTrust Intrusion Detection System 3.0, which in turn weakens a company's defence against a DoS attack, said Michael Sutton, director of iDefense Labs.

The vulnerability stems from CA's intrusion detection system failing to check whether data is the correct size before passing it off to Microsoft's Crypto API function CPImportKey. Microsoft's Crypto API function CPImportKey also does not check the data once it has been passed on, Sutton said. As a result, any incorrectly sized data will create a problem with the memory, creating a buffer overflow.

Sutton warned that other application vendors who use Microsoft's Crypto API function CPImportKey and whose own products also do not check the data's size before passing it on to the Microsoft API may face the same vulnerability.

"This vulnerability is not overly difficult to exploit," Sutton said.

CA, which was initially notified of the flaw in early December, has issued an update for version 3.0 and 3.0 SP1, which includes a work-around to prevent the flaw from being exploited, said a company spokeswoman, declining further comment.

The eTrust Intrusion Detection vulnerability marks the latest security issue for CA. Last month, exploit code was discovered that could take advantage of flaws in CA's licensing software and launch a DoS attack.

In that particular case, the amount of time between the public disclosure of the vulnerability and the development of code to exploit the flaw was only a week. Security experts have become increasingly concerned over the speed in which malicious code generally appears after a vulnerability has been announced.

  • Email
  • Trackback
  • Clip Link
  • Print friendly Print with HP

Did you find this article useful?
72 out of 145 people found this useful


Full Talkback thread

0 comments


Company/Topic Alerts

Create a new alert from the list below:






Related Jobs

City Investment Bank - Snr Front Office Dev - Murex/Flex API

The successful candidate will need Murex experience and Flex API knowledge. A city based investment bank is looking for a snr developer to join a ...

Blackberry API developer - London - Good rates

We are looking for an experienced Blackberry developer with extensive knowledge of BlackBerry API, who is aware of the BlackBerry API limitations. He ...

Security Consultant Ethical Hacking / Penetration Testing - London

Responsibilities: - Deliver security assessment services including network scanning, vulnerability testing, penetration testing, search engine ...

Sentry Posts Blog

Mobile Linux Better For Mobile Busines...

Mobile Linux Better For Mobile Business Apps? Author: Eric Everson, MyMobiSafe.com As mobile Linux is carving it’s footprint on the future of mobile application development, the... More

Post a comment

DWP downplays security breach

The Department for Work and Pensions (DWP) has admitted that some of its staff have been forwarding passwords with password protected material. An email that was leaked on the 'Dizzy... More

Post a comment

How many headshots does one chairperso...

We got a strange request last week from the head of PR from Russian security experts Kaspersky. It seems although the company was very happy with the interview we recently carried with... More

Post a comment

Featured Talkback

On the contrary, if vendors were forced to stand behind their products it should increase innovation. It would force more, and better , testing before hitting the sales floor, resulting in fewer updates and less downtime for the consumer. At present the EULA removes responsibility from the vendor, and moves it to the user, which is a step backward. Make the vendor responsibility for their code.

By: ator1940

Read full story:
RSA: Vendor liability may stifle innovation