Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
FTC v. Wyndham: Naughty 9 Security Fails to Avoid
Newest First  |  Oldest First  |  Threaded View
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
9/29/2015 | 12:28:13 PM
Re: Point 3
I am all for the nuclear option...unfortunately I don't think the business side will be on board.
Jason.straight@unitedlex.com
50%
50%
[email protected],
User Rank: Apprentice
9/28/2015 | 6:36:43 PM
Re: Point 3
The nuclear option (i.e. stop using Java) has been recommended by some security pros and is the only one i am aware of that will truly solve this problem, but that is probably not the response you're looking for.  I'll let the IT security ops folks weigh in on this but Java seems to occupy its own special island in the patch management world for exactly the reasons you highlight.  It's a classic situation of balancing security against business needs - you can patch aggressively (and even automatically) and risk breaking apps and disrupting business or you can continue rolling the dice by not patching in a timely fashion.  The middle ground might be to try to assess the risk and potential impact of each newly disclosed Java vulnerability in YOUR environment and make prioritizing decisions on a patch-by-patch basis. 

If I had a better idea, I would sell it to Oracle and buy my own special island!

Anyone else have suggestions?

 

 
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
9/28/2015 | 3:04:08 PM
Point 3
Its amazing the amount of organizations that are heavily tech-ified not having an efficient patching process. There are gaps unfortunately even with efficient patching processes when it comes to legacy apps.

IE: When an app is coded for a specific version of Java, even though all Java versions are backwards compatible of each, it will not perform as intended due to the hardcoding. Due to this, older versions that are vulnerable will remain on the network. How could this best be handled to avoid the one of the Naughty 9?


News
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Commentary
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-20001
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.2.0, BinaryHeap is not panic-safe. The binary heap is left in an inconsistent state when the comparison of generic elements inside sift_up or sift_down_range panics. This bug leads to a drop of zeroed memory as an arbitrary type, which can result in a memory ...
CVE-2020-36317
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the sam...
CVE-2020-36318
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
CVE-2021-28875
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
CVE-2021-28876
PUBLISHED: 2021-04-11
In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety r...