Venom, as described by its discoverer, Crowdstrike, an end-point security company, works by attacking QEMU's virtual Floppy Disk Controller (FDC). The first thing many of you think when learning this is: "Who cares, I've never used a floppy drive on my virtual machine (VM)!"
Ah, but, you don't have to activate the virtual floppy drive for a potential hacker snake to bite you. By default, the legacy floppy drive code is still in there, even though it's never been used. The corruption is still hiding in the code. So, even though you'd never dream of using a VM floppy drive, you're still open to attack.
Linux is engineered with security in mind. In fact, the most fundamental security mechanisms are built right in to the kernel itself, which makes it extremely hard for malicious code to bypass. Unfortunately, attackers always are looking for ways to break down security walls, and engineers constantly are patching security weaknesses.
Security holes often are caused by small bugs within the kernel. These can be exploited and used to execute code without the normal protection. When a serious hole is discovered, it's important to get a fix out as soon as possible. Unfortunately, rushed fixes sometimes cause problems of their own, such as the fix released by Canonical earlier this week.
Linux distributions can be separated into various categories based on use case and the intended target group. Server, education, games and multimedia are some of the most popular categories of Linux distros.
For security conscious users, however, there's a growing niche of distros aimed at protecting your privacy. These distros help ensure you don't leave a digital footprint as you go about navigating the web.
At a time when faith in open source code has been rocked by an outbreak of attacks based on the Shellshock and Heartbleed vulnerabilities, it's time to revisit what we know about Linux security. Linux is so widely used in enterprise IT, and deep inside Internet apps and operations, that any surprises related to Linux security would have painful ramifications.
In 2007, Andrew Morton, a no-nonsense colleague of Linus Torvalds known as the "colonel of the kernel," called for developers to spend time removing defects and vulnerabilities. "I would like to see people spend more time fixing bugs and less time on new features. That's my personal opinion," he said in an interview at the time.
This post is aimed to clarify certain terms often used in the security community. Let’s start with the easiest one: vulnerability. A vulnerability is a flaw in a selected system that allows an attacker to compromise the security of that particular system. The consequence of such a compromise can impact the confidentiality, integrity, or availability of the attacked system (these three aspects are also the base metrics of the CVSS v2 scoring system that are used to rate vulnerabilities). ISO/IEC 27000, IETF RFC 2828, NIST, and others have very specific definitions of the term vulnerability, each differing slightly. A vulnerability’s attack vector is the actual method of using the discovered flaw to cause harm to the affected software; it can be thought of as the entry point to the system or application. A vulnerability without an attack vector is normally not assigned a CVE number.
Using the proprietary OOXML document format, i.e. docx, pptx and xlsx, makes you more vulnerable to phishing and other attacks. Earlier this month, the Japanese anti-virus company Trend Micro published a blog post describing how the attack group "Operation Pawn Storm" uses spear-phishing mail messages with malicious Office documents to target the military, governments, defense industries and the media.
Four years ago, Thomas Caspers and Oliver Zendel from the German Federal Office for Information Security (BSI) already presented research results stating that most spear-phishing attacks targeting specific persons or a small group of victims are using "launch actions" in Office and PDF documents to have their malicious code executed.
Greg Knaddison has worked for big consulting firms, boutique software firms, startups, professional service firms, and former Drupal Security Team leader. He is currently the director of Engineering at CARD.com and a Drupal Association advisory board member.
Michael Hess works with the University of Michigan School of Information and the UM Medical Center teaching three courses on content management platforms and overseeing the functionality of hundreds of campus websites. He serves in a consulting and development role for many other university departments and is the current Drupal Security Team leader. He also consults with BlueCross on large-scale medical research projects. Hess is a graduate of the University of Michigan School of Information with a master's degree in information.