Oracle quarterly patches on black tuesday
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:
- Oracle Database (9 vulnerabilities),
- Oracle Application Server (7 vulnerabilities),
- Oracle Collaboration Suite (1 vulnerability),
- Oracle E-Business Suite and Applications (5 vulnerabilities),
- Oracle enterprise manager (2 vulnerabilities),
- Oracle PeopleSoft and JD Edwards Applications (5 vulnerabilites),
- Oracle Siebel (6 vulnerabilities), or
- BEA Product Suite (6 vulnerabilities)
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
October Black Tuesday Overview
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 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 |
|||||
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 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 appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- 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
Day 14 - Containment: a Personal IdentityTheft Incident
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:
- Reported the fraud to the FTC.
- 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.
- Called Capital One and reported the fraud.
- Called Mighty Net and reported the fraud. They immediately canceled the online account used to request and access my credit history.
- Filed a report with the police department.
- 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.
- Reviewed my husband's credit history to make sure he was not a victim of identity theft.
- 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)
- 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.
- 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
Comments