Hi, it's Will and Art here. We've been telling people to disable Java for years. In fact, the first version of the Securing Your Web Browser document from 2006 provided clear recommendations for disabling Java in web browsers. However, after investigating the Java 7 vulnerability from August, I realized that completely disabling Java in web browsers is not as simple as it should be.
In this post I'll explain how to expand on David Beazley's cobroadcast pattern by adding a join capability that can bring multiple forked coroutine paths back together. I'll apply this technique to create a modular Python script that uses gcov, readelf, and other common unix command line utilities to gather code coverage information for an application that is being tested. Along the way I'll use ImageMagick under Ubuntu 12.04 as a running example.
Hi, this is Austin Whisnant of the CERT Network Situational Awareness Team (NetSA). After a long time in the making, NetSA has published an SEI technical report on how to inventory assets on a network using network flow data. Knowing what assets are on your network, especially those visible to outsiders, is an important step in gaining network situational awareness.
While researching how to successfully mitigate the recent Java 7 vulnerability (VU#636312, CVE-2012-4681), we (and by "we" I mean "Will Dormann") found quite a mess. In the midst of discussion about exploit activity and the out-of-cycle update from Oracle, I'd like to call attention to a couple other important points.
Last Sunday, another major Java vulnerability (VU#636312) was reported. Until an official update is available, we strongly recommend disabling the Java 7 plug-in for web browsers.
This vulnerability is bad news, at least for those of us trying to avoid phishing and drive-by browsing attacks. The vulnerability is caused by a logic bug that allows an applet to grant itself full privileges. More technical details are available in Vulnerability Note VU#636312.
Hi folks, Allen Householder from the CERT Vulnerability Analysis team here. Back in April, we released version 1.0 of the CERT Failure Observation Engine (FOE), our fuzzing framework for Windows. Today we're announcing the release of FOE version 2.0. (Here's the download.) Although it has only been a few months since we announced FOE 1.0, our development cycle is such that FOE 2.0 actually reflects nearly a year of additional improvements over the 1.0 release.
As U.S. Department of Defense (DoD) mission-critical and safety-critical systems become increasingly connected, exposure from security infractions is likewise increasing. In the past, system developers had worked on the assumption that, because their systems were not connected and did not...