Oracle quarterly patches on black tuesday

Published: 2008-10-14
Last Updated: 2008-10-14 23:52:11 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Oracle released it's quarterly accumulated patches today.

For those that do patch their databases, I'd suggest you round up your DBAs and run over these with them as well as your server administrators who'll get potentially a lot more work as well on "reboot wednesday".

Oracle released fixes for:

If you run any of them, you need to review the fixes available. Oracle does provide CVSS ratings for the vulnerabilities.

When two monster patch cycles collide on the same day, I guess a few will get overworked. Same thing is likely to reoccur on their next scheduled release on January 13th, 2009.

--
Swa Frantzen -- Section 66

Keywords: oracle patches
0 comment(s)

October Black Tuesday Overview

Published: 2008-10-14
Last Updated: 2008-10-14 22:43:03 UTC
by Swa Frantzen (Version: 1)
0 comment(s)

Overview of the October 2008 Microsoft patches and their status.

# Affected Contra Indications Known Exploits Microsoft rating ISC rating(*)
clients servers
MS08-056 Cross site scripting (XSS) in the way Office XP SP3 handles the dialog window for the content-disposition:download and the cdo: protocol.
Office

CVE-2008-4020
KB 957699 No publicly known exploits Moderate Important Less Urgent
MS08-057 Multiple vulnerabilities in Excel lead to random code execution. This also affect sharepoint server.
Replaces MS08-043.
Office

CVE-2008-4019
CVE-2008-3471
CVE-2008-3477
KB 956416 No publicly known exploits Critical Critical Critical
(**)
MS08-058 Multiple vulnerabilities in MSIE lead to random code execution and or information leaks.
Replaces MS08-045.
IE

CVE-2008-2947
CVE-2008-3472
CVE-2008-3473
CVE-2008-3474
CVE-2008-3475
CVE-2008-3476
KB 956390 CVE-2008-2947 is publicly known Critical Critical Important
MS08-059 RPC requests can bypass authentication and lead to random code execution.
Host Integration Server (HIS)

CVE-2008-3466
KB 956695
No publicly known exploits Critical Important Critical
MS08-060 A buffer overflow in the LDAP services allows random code execution. LDAP over SSL is also afected.
Replaces MS08-035.
Windows active directory

CVE-2008-4023
KB 957280 No publicly known exploits Critical N/A Critical
MS08-061 Multiple vulnerabilities in the windows kernel allow privilege escalation.
Replaces MS08-025.
Windows kernel

CVE-2008-2250
CVE-2008-2251
CVE-2008-2252
KB 954211 No publicly known exploits Important Important Important
(***)
MS08-062 An Interger overflow in IPP allows random code execution to authenticated users.
Windows internet printing (IIS)

CVE-2008-1446
KB 953155 Actively exploited in targeted attacks Important Less Urgent (****) Critical
MS08-063 Crafted filenames lead to random code execution in the SMB protocol.
Replaces MS06-063.
Windows file sharing

CVE-2008-4038
KB 957095 No publicly known exploits Important Important Critical
MS08-064 An integer overflow allows privilege escalation.
Replaces MS07-066, MS07-022 and Advisory 932596.
Windows virtual address descriptor

CVE-2008-4036
KB 956841 No publicly known exploits Important Important Important
MS08-065 An input validation failure in an RPC of MSQS allows random code execution.
Windows 2000 message queuing

CVE-2008-3479
KB 951071 No publicly known exploits Important Important Important
MS08-066 An input validation failure allows privilege escalation.
Windows ancillary function driver

CVE-2008-3464
KB 956803 No publicly known exploits Important important Less Urgent
(***)
Advisory
956391
Killbits for 3rd party (Microgaming, System Requirements Lab, PhotostockPro) as well as Microsoft ActiveX controls mentioned in MS02-044, MS08-017, MS08-041 and MS08-052.
IE Active X killbits
KB 956391   - Critical Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): For sharepoint servers. Important for others.

(***): for shared servers this is most likely critical.

(****): assuming no IIS was installed.

--
Swa Frantzen -- Section 66

0 comment(s)

Day 14 - Containment: a Personal IdentityTheft Incident

Published: 2008-10-14
Last Updated: 2008-10-14 14:02:55 UTC
by Swa Frantzen (Version: 2)
2 comment(s)

Containing a IDtheft incident can be seen from multiple sides.

The organization leaking the sensitive information by accident

As always being prepared is key to reacting properly. Randy wrote: "An organization must identify and classify personally identifiable information (PII) in order to contain the accidental disclosure that could result in consumers being exposed to identity theft." Information processing for such information could be segregated from the mainstream of the systems and be placed under closer monitoring and tighter security measures.

But if it does go wrong you need an action plan involving key stakeholders in order to abide local laws and regulations as well as protect the interests of the individuals who confided the sensitive data to the organization. Randy goes on: "This data breach plan should be be tested much like a disaster recovery plan to ensure that each team member understands their role."

Still how do you plan to contain a breach?

Depending on what was identified as leaked, the plan should at least consider how to most effectively

  • Consider requirements form a legal and regulatory viewpoint
  • Communicate the problem to affected individuals so they can assist from their end
  • Offer some sort of protection to the affected individuals
  • Cover any wanted or unwanted media attention appropriately
  • Work with authorities and law enforcement

 

The individual having his personal information exposed.

What better to learn than from a victim. Laura stepped up with her condensed version:

"I recently became a victim of identity theft. The beginning of October I received a letter indicating my information had been exposed http://www.bnymellon.com/tapequery/. This is an incident that occurred in February 2008 and it wasn't until October 2008 that I was notified. I was upset that 8 months passed before I was notified. I immediately signed up for the free 2 year credit monitoring service offered. Days later I received another letter from Capital One indicating someone had applied for (and received) a credit card in my name although some information did not agree with my credit history. Capital One asked me to contact them. I immediately reviewed my credit history and found that Capital One performed a credit inquiry for someone with my name located in another city about 150 miles from my home - the address was listed in my credit history. Additionally, the perpetrator also obtained a copy of my credit history from a company I've never heard of before - Mighty Net. All this occurred before I received the letter from BNY Mellon.

So far I have:

  1. Reported the fraud to the FTC.
  2. Immediately requested a 90 day fraud alert or credit freeze with Experian, Transunion and Equifax. This was a temporary move until I could obtain a permanent freeze.
  3. Called Capital One and reported the fraud.
  4. Called Mighty Net and reported the fraud. They immediately canceled the online account used to request and access my credit history.
  5. Filed a report with the police department.
  6. Obtained copies of the police report and sent it with a  notarized document confirming my identity (http://www.ftc.gov/opa/2002/02/idtheft.shtm) to the three credit bureaus requesting a seven year credit freeze using USPS certified return receipt.
  7. Reviewed my husband's credit history to make sure he was not a victim of identity theft.
  8. Sent notarized certified return receipt letters to Capital One and Mighty Net of INITIAL VICTIM OF IDENTITY THEFT STATEMENT AND FRAUDULENT ACCOUNT INFORMATION REQUEST (http://www.idtheftcenter.org/artman2/publish/v_templates/Letter_Form_100_-_1.shtml)
  9. Wrote certified return receipt letters to all the companies listed in my credit history requesting all infrequently used accounts be canceled to prevent further exploitation of this fraud.
  10. Contacted BNY Mellon to inform them that I am a victim of identity theft.

I can't help but wonder - was this identity theft the result of the BNY Mellon lost tape incident or is there another incident that has not yet been identified for which there are other victims?

An event like this really takes an emotional toll on the victim and family. I recommend everyone place a credit freeze or monitoring on their credit history. It may not prevent identity theft but it can put the investigation into motion early. Finally, document everything - every phone call and every action you take. Treat it like your own forensic investigation. You may need the information later."

 

Living in a county where the issue is much more privacy, not by far not so much IDtheft (we have decent ways to authenticate ourselves), I'm counting on your feedback on how you plan to contain such incidents, and will update it with submssions we receive.

--
Swa Frantzen -- Section 66

Keywords: Awareness2008
2 comment(s)

Comments


Diary Archives