Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security features
We found -1 articles for you...
102
secure developmentrisk assessmentmemory safetyWhy Memory Safety Is Becoming a Core Requirement in Modern Software
Most information security best practices are built on a single, comfortable assumption: that we have control over what software is running on our hardware, and that the underlying system behaves exactly as we expect. We assume that the memory management happening under the hood is a solved problem—a silent utility that stays within its lines. . But the data from the world's largest tech giants just blew that theory apart. From Microsoft to Google, the telemetry is consistent: roughly 70% of all serious software vulnerabilities are memory safety issues. We aren’t just dealing with occasional glitches; we are dealing with a structural failure in how we’ve built software for forty years. The Hidden Layer of Software Security Everyone Ignores When we discuss how to secure a system, we usually focus on the perimeter: hardening SSH, configuring firewalls, and managing user identities. But there is an invisible layer of legacy code and memory-unsafe programming languages running in the background that most admins never touch. Many of the most common software vulnerabilities—like buffer overflows and use-after-free errors—stem from how applications manage memory. Languages like C and C++ are the bedrock of our infrastructure, but they operate on an "honor system." They give developers total control over system memory, but they offer no guardrails. Academic and technical research—such as studies on memory safety issues and vulnerabilities in C/C++ systems —confirms that memory safety issues are a primary cause of kernel and system vulnerabilities. The problem? You can harden your network security all day, but if the foundation is written in an unsafe language, you’ve left a root-level power tool sitting on the counter for anyone to pick up. True system security isn't just about who can get into the box; it's about what the box is allowed to do once they're there. How Memory Safety Breaks System Security The technical failure here is a classic lack of boundaries, butthe design failure is much deeper. In a healthy system security model, trust should be atomic—it either exists or it doesn't. Memory-safe languages (like Rust) enforce this at the compiler level. They check if the data belongs in that memory space, and if it doesn't, the code simply refuses to compile. Memory-unsafe languages break this by splitting trust across layers. The developer has to manually verify every single pointer, and the moment there is a gap between the check and the action, the gap becomes a playground for exploits. Why Endpoint Security Doesn't Catch This This is where the reality of endpoint security gets uncomfortable. Most security tools are designed to look for "bad" things: known malware signatures, suspicious network traffic, or unauthorized binary execution. Memory corruption or a buffer overflow doesn't look "bad" to a standard monitor: The process is a legitimate system component. The action is a legitimate system function. The error happens entirely in the background. Security tools trust the same system components that attackers abuse. If your security strategy is purely reactive, it will stay silent while the system's own "trusted" tools are used to dismantle it from the inside. Linux and Rust: A Signal, Not the Story When a vulnerability is widespread, it stops being a local issue and becomes a massive failure in secure software development, as detailed on the OSS-Security mailing list and industry research. This isn't just a misconfiguration; it's the default behavior shipped to millions of users. Distribution Default Language Risk Profile Ubuntu / Debian Predominantly C/C++ High (The backbone of many servers) RHEL / Fedora Mixed C / Legacy Medium-High (Enterprise standard) The adoption of Rust in the Linux kernel is the clearest signal we have that the tide is turning. This shift is especially visible in Linux kernelsecurity , where new components are increasingly written with memory safety in mind. As noted in recent reports on Linux kernel adoption, this isn't about replacing every line of C overnight. It’s about starting with the most dangerous parts: drivers and new kernel components. By bringing open source security to the core of the operating system, Linux is demonstrating that even the most critical infrastructure can—and must—evolve without sacrificing performance. Rust-based drivers are already proving safer than C-based ones. Rust improves memory safety , concurrency safety, and performance simultaneously. You can also get a clear visual summary of how the integration functions by watching the Linux 7.0 and Rust Integration video . Breaking the Information Security Model We need to be clear about the stakes: Root access is total access. All your software security best practices assume that you have control over what software is running on your hardware. If an attacker can exploit a memory bug to gain arbitrary code execution or escalate privileges, that control is gone. They don't need to crack your database encryption; they can just pull the keys directly from memory. Your entire policy model is built on the assumption that software execution is a privileged, controlled act. Vulnerable, memory-unsafe code turns that act into a free-for-all. How to Secure a Server Right Now (Without Waiting) Most environments should not be relying on unsafe dependencies or unverified memory access where it can be avoided. Here is how to secure a server against this class of vulnerabilities: Audit: Check your dependencies and system binaries for unmanaged C/C++ libraries. Isolate: Stop using unneeded background helper services. If you don't need a middleman, kill the service and mask it so it can't be "woken up" by other processes. Patch/Migrate: Ensure your environments are utilizing up-to-date, securely compiled packages and dependencies. The Real Lesson: StopTrusting Default System Behavior If there is one thing that cybersecurity best practices consistently get wrong, it’s the idea that "default" equals "safe." Defaults prioritize usability. They want the system to "just work" for the broadest number of people. But security assumes correct behavior, and reality breaks both. If structural flaws can sit in default installs across every major distribution, the problem isn’t a lack of patching; it’s a lack of skepticism. The most dangerous systems are the ones that look normal. Security isn't about the tools you've installed. It's about the trust you've refused to give. Stop trusting that the "standard" install has your back. Start validating the foundation. . Explore the critical nature of memory safety in modern software and its impact on system security and vulnerabilities.. Memory Safety, Software Security, Secure Development Practices, System Integrity. . MaK Ulac
Apr 30, 2026
•
102
security practicessoftware securitymitigation strategiesMitigating Open-Source Software Risks for Enhanced Security
Open-source software, or OSS , has completely changed the technology sector by enabling developers anywhere to work together and produce creative solutions faster. However, security issues are a significant worry, just like in any digital environment. Therefore, you should take precautions to secure any open-source software you use. . Businesses repurpose open-source software and must have a strategy to handle the open-source security threats that could be introduced into their IT estates by third-party source code. This article explains how to manage open-source software security risks and vulnerabilities and defines how to achieve robust open-source security. What Are the Security Risks of Open-source Software? Most people use open-source software due to its freedom to modify and customize the code according to user needs. Even people look for open-source streaming devices as most are locked to be used with the manufacturer's recommendation. For example, Amazon Fire Stick comes locked to be used with specific services like Prime Video, Netflix, HBO Max, and other popular streaming services. However, many users want to use the device as per their requirement and prefer using more services for which they choose to unlock their device. Now, unlocking your Amazon Firestick opens the door to exploring more apps and streaming services. The advantage of doing this is that users can use affordable and free services to meet their needs. Although unlocking any device brings some security concerns, that happens with every open-source tool or software that allows customization or modification. To learn more about OSS security threats, let's examine a few security concerns that may come from using open-source code. Known Vulnerabilities The most dangerous security risk is open-source code with a known security flaw. Security flaws are documented in open databases such as MITRE CVE . The databases describe the software versions susceptible to attack and provide instructions on launching theattacks. Although developers can use this information to address security flaws, attackers can also utilize it to exploit software vulnerabilities. As a result, attackers can quickly take advantage of open-source modules, libraries, or other components used by businesses that are vulnerable to known security flaws. Inaccurate Setups Businesses occasionally utilize open-source software that is not set up in the safest manner feasible. Businesses may, for instance, use open-source container images that execute commands as root (unsecured). Alternatively, depending on a business's specific requirements, a sophisticated open-source platform may come with access control settings that are not overly permissive. In certain situations, maliciously designed software may facilitate or broaden attackers' attack surface for exploiting vulnerabilities. Lack of visibility Sometimes, programmers use open-source code without properly crediting the author or documenting the source. It becomes challenging to guarantee that they adhere to standard practices for securely handling the code. For example, the code's original authors may have provided documentation on configuring it safely. Still, if the code is reused in a way that makes it unclear where it originated from or what security precautions its creators advised, it might be challenging to follow those guidelines. How Can I Mitigate the Risks of Open-Source Software to Achieve Robust Security? Luckily, there are practical measures you can take to mitigate the risks discussed above and achieve robust open-source security: Identify open-source risks. Organizations risk legal action and intellectual property theft if open-source licenses are broken. Similarly, using antiquated or subpar components might lower the caliber of applications that utilize them. Do you have the most recent version of the open-source component installed? Is it the steadiest? Does a strong community actively maintain the component? Examine your available sources. Makingan inventory of all the open-source components your teams utilize to produce software should be your first step because you can't secure what you're not tracking. A comprehensive inventory must include every open-source component, the version(s) used, and the download locations for all active and upcoming projects. All dependencies—the libraries your code references and/or the libraries to which your dependencies are linked—must also be listed in your inventory. Employ the best IT professionals. If you still need to acquire in-house human capital for your open-source projects, your first move should be to bring the right people on board or locate the best software outsourcing provider. Severe vulnerabilities can be easily caused by an open-source community devoid of security expertise and a security team that lacks an understanding of the project design. When employing candidates, evaluate their knowledge practically rather than just focusing on their credentials. Even if someone has all the qualifications on paper, you shouldn't hire a Linux security expert who has never heard of Apache Struts. Select a strong password, and keep it confidential. The cornerstone of any open-source project's security is password protection. Don't share your password with anyone; never use a password visible to everyone. It is advisable always to think that someone is observing you and trying to obtain your passwords. Strong passwords and a password manager are reasonable security measures. Maintain privacy for your open-source project. Verify someone's identity and motive whenever they request access. When in doubt, refuse entry, and be mindful of the dangers of permitting excess. When signing your releases, use a code-signing certificate. Code signing certificates are the digital security credentials needed to sign scripts and executables containing your software's cryptographic key. These digital signatures guarantee that the file is authentic and hasn't been altered since your private key was used to signit. SSH is the protocol of choice for accessing your code repositories. If you're using the Git or Subversion source control management system, use SSH to access your repositories. This guarantees you can only connect with the proper credentials and stop brute-force assaults. Backup and encrypt your data and files. Encrypting and backing up your data and files is crucial in ensuring your OSS is secure. Encryption can shield your data from theft or unwanted access, mainly if you use OSS on cloud or mobile platforms. You can use programs like LUKS , VeraCrypt , or GnuPG to encrypt your data. Backups can aid in data recovery during data loss, corruption, or ransomware attacks. Instruct and prepare yourself and your users. Lastly, you should train and educate yourself and your users on open-source software's hazards and best practices. Adhering to the directives and suggestions provided by open-source software development (OSS) groups and reliable resources such as OWASP , NIST , or SANS is advisable. Additionally, you should instruct your users on how to stay safe from common dangers like phishing and malware. Check your code frequently for security flaws. The best way to automate your code audits is to use code audits. They don't need human assistance to identify common weaknesses. Using Git hooks , you may set them up to execute automatically with each new commit or pull request. This guarantees that all units in your repository are scanned for security flaws each time a new branch for a feature set is created. Our Final Thoughts on Open-Source Software Security An open-source project that is secure has a much higher chance of success than one that is insecure. Although there are many things you can do to make sure your project is effectively safeguarded, any secure open-source venture must surely start with the recommended practices covered in this article. Checking for vulnerabilities regularly can help you know what changes to make in your open-source securitystrategy. Moreover, training your staff to identify and rectify security risks can help your company enhance the security of your software and data. . Explore methods to handle vulnerabilities in open-source projects and discover best practices for ensuring resilient security measures.. Open-Source Software,Risk Mitigation,Security Strategies,OSS Management. . Brittany Day
May 05, 2024
•
102
Red Hatacquisitionopen sourceIBM Closes $34 Billion Acquisition of Red Hat and Its Impact on Open Source
In the tech giant’s largest deal ever and one of the biggest deals in US history, IBM closed its $34 billion acquisition of Red Hat on Tuesday July 9, 2019. Red Hat will now be a unit of IBM’s hybrid cloud division and Red Hat CEO Jim Whitehurst will join IBM’s senior management team. This event has significant meaning that extends beyond is monetary value: it is a testament to the power of Open Source and the opportunity it offers businesses of all sizes across all industries. . Organizations choose open source because it allows them to build high-quality software faster and more securely than proprietary alternatives. Open source development is more rapid, with updates occurring on a more frequent basis. It is decentralized, so disparate groups from around the world collaborate and build a community where many stakeholders contribute, customizing and improving it for everyone along the way. The collaborative nature of Open Source fosters rapid innovation as a competitive advantage, with ideas coming from multiple independent sources as opposed to a single proprietary vendor. Open-source software and technology offer advantages in security and reliability, resulting from large deployments and the scrutiny from experts worldwide that open-source code undergoes. Well-designed open-source products and solutions provide: 1. Eliminated risk of vendor lock-in 2. Cost-effective implementation 3. Adherence to community values, ethics. It’s developed by the same people who use it themselves 4. Fewer vulnerabilities, fixed more rapidly 5. Increased reliability with a worldwide community supporting a code base rather than one team within one company 6. Better security - open source software’s code is often more secure because it is much more thoroughly reviewed and vetted by the community Pioneers in Open Source & Cyber Security Dave Wreski, Guardian Digital founder and CEO and passionate open-source community member and contributor, believes that Open Source is wherethe innovations in technology are occurring. He continues, “If you're developing the next big thing, you're doing it using Open Source.” Guardian Digital collaborates with many of the same building blocks developed by other Open Source contributors including IBM and Red Hat. Our software is created, developed, and built upon by software engineers freely. This generates more rapid innovation, with ideas coming from multiple independent sources, improving reliability and security compared to proprietary alternatives, which often have a reactive rather than proactive approach to cyber attacks. Since its inception in 1999, Guardian Digital has recognized that the open-source model provides the best approach to the problem of maintaining security in the relentlessly dynamic environment of the Internet. The ideals that the open-source community follows and hold dear — community engagement, openness, collaboration — are also the ideals that Guardian Digital holds among its main tenets. It’s a reflection of an environment that is highly collaborative, and where the best solution always comes out ahead. In this environment — where flexibility, choice, and an affordable costs are built into the process — Guardian Digital customers win. The future is open-source, and email security is no exception! How is your company using or contributing to Open Source? We’d love to hear about it :-) . Explore the implications of Microsoft's purchase of GitHub as a transformative step in the realm of collaborative development and code cohesiveness.. acquisition of Red Hat, IBM cloud technology, open source benefits, software security advantages. . Brittany Day
Jul 11, 2019
•
102
risk managementsecurity analysissoftware securityInterview: Gary McGraw Discusses Software Security and Exploitation
Gary McGraw is perhaps best known for his groundbreaking work on securing software, having co-authored the classic Building Secure Software (Addison-Wesley, 2002). More recently, he has co-written with Greg Hoglund a companion volume, Exploiting Software , which details software security from the vantage point of the other side, the attacker. He has graciously agreed to share some of his insights with all of us at LinuxSecurity.com.. LinuxSecurity: Gary, please give our readers a brief introduction to your new book, Exploiting Software: How to Break Code (ISBN 0-201-786-95-8). Who does the book appeal to? Where can it be purchased? Gary McGraw: Traditionally, the field of computer security has been about network and operations people -- think network administrators and IT staff. The basic idea was to build a wall around your networks, protecting your vulnerable stuff (inside) from bad people (outside). The problem with this approach is twofold. First off, "perimeter security" is, at its essence, reactive. Secondly, there is no such thing as a well-defined "perimeter" anymore now that distributed systems are so widespread. The advent of Web services, mobile code, and Internet-based computing makes the notion of perimeter security seem quaint. Furthermore, the attackers have a distinct advantage, since they only need to find one flaw to exploit, while the defenders have to find and remove them all. In the end, the vulnerable stuff is software, and a lot of software is so buggy that it's almost impossible to protect. Because of all this, there has been an increasing interest in software security. That means one of the key questions to consider is, how do you harden software against attack? The only reasonable way to do this is to deeply understand just what attacks are. After all, how can you know that your company's critical software is secure, and that it has been built with security in mind, if you really know nothing about what the attacks on it are like? In thissense, Exploiting Software is useful to operations people, and to their management. By knowing how the software living on and making up their network is likely to be attacked, a good network admin is better equipped to manage risks. Only by understanding how easily buggy software can be compromised can CIOs begin to apply the kind of risk management that business demands to the software they rely on. Our book is also useful to software developers. It is vital that the people who build our systems (including Linux) learn to look at their software creations not just as a collection of features, but as potential targets for hackers and their nefarious exploits. It only makes sense for builders to get into the mind of their attackers so they know what they are really up against. For more information about buying a copy of Exploiting Software for yourself (and your entire development staff), check out www.exploitingsoftware.com. The publisher, Addison-Wesley Professional, also has a website too. LS: Can you offer a brief description of your background and that of your co-author, Greg Hoglund? How did you two meet or decide to co-write a book? How long have you been in the software security field? How would you say this collaboration has enriched the book? GM: First, I'll answer for myself. I am a scientist at heart, and I've been playing with computers ever since I got an Apple II+ in 1981. I studied the lucrative field of Philosophy at the University of Virginia and, inspired by the Pulitzer Prize winning book by Douglas Hofstadter Godel Escher Bach , I ended up earning a dual PhD in Computer Science and Cognitive Science from Indiana University (where Doug was my thesis advisor). Around 1985, I got interested in the 'Net. In 1993 we put up one of the first 400 nodes on the Web (Yahoo was a complete list of all websites back then). In 1995, Java came out, and being a programming languages and Web junkie, I downloaded it. Investigating itsinteresting claims of being a "secure" computing platform led to my first book, Java Security , written with Ed Felten of Princeton. After that, the need for some good work in software security became obvious. In 2001 I wrote the first book in the world on software security, called Building Secure Software with John Viega. Greg Hoglund started out as a black hat. In contrast to my academic background, he was completely self taught, and has the innate ability to think like a hacker. In fact, he wrote the first rootkit for Windows NT, and started in the process. We became friends some years ago and he agreed to co-write this book just after the publication of Building Secure Software . The idea was to look at a large corpus of attacks and exploits and see if we could discern any patterns in these attacks. Greg's expertise was absolutely critical to this undertaking, and his thinking pervades the technical aspects of the book. LS: You have previously written a book called Building Secure Software , which covered the design and implementation of secure code for the software developer. Can you explain why we might also a primer for black hats, such as Exploiting Software ? GM: Actually, Greg and I call Exploiting Software the black hat book (in contrast to BSS which is the white hat book)! Together, the two books make up the "black and white series." The reason we saw the need for the black hat book is that we strongly believe that you simply cannot build a defensible, secure system without knowing how people will attack it. The bad guys already understand software. In fact, they are software people. They know how to write code, they know what bugs to look for, and they know how to exploit them. They can hold a security patch up against a broken piece of software and use it as a roadmap for writing a new exploit. Unfortunately, on the other side of the divide, most security operations people do not understand software. They are excellent firewalland router admins, but they don't code. That's a problem. LS: What are some of the most major pitfalls that software designers fall into? Can your book help to avoid these problems? GM: In the book, we provide a set of 49 attack patterns. Attack patterns are directly related to pitfalls and problems that we see in real production software today. One of the points I like to emphasize is the difference between bugs and flaws in software. Bugs are simple mistakes in code leading to problems like buffer overflows; flaws are mistakes in design. It turns out that a lot of software is flawed. In fact, if you step back and look at a multitude of security problems over time, you'll find that about 50% of them are due to bugs and 50% due to flaws. There are too many common design failures to list exhaustively here. But here are a couple of examples... Object Oriented programming is the latest, greatest widespread coding paradigm, and it can indeed be very useful. But the distributed code model has a cost: each class (and possibly every method) is expected to do its own error handling, meaning that there is not necessarily an inherently centralized error handling mechanism. This means that it becomes difficult to determine exactly what will happen at various points of failure. Keeping track of precisely what is going on in the software as it throws exceptions willy nilly is difficult at best. Error handling is complex, and complexity is a great friend to attackers. Without some ability to manage errors in a consistent system wide fashion, it becomes nearly impossible to be sure that nothing intentionally bad could be made to happen. Then there is the more general concern that software designers tend to be a very feature-oriented crowd. They build things, and things have features. So they naturally default to thinking about security as a set of features (think SSL or access control). The problem is that security is an emergent property of a complete system. Related to this "featurism," is a related problem involving trust. Developers tend to have too much trust to their users, and do not treat user input with due suspicion. They think, "users want to access these features," instead of "attackers might abuse my system in surprising ways." These are just a few high level issues that can render software insecure. There are many, many more where these came from. LS: What practical steps can be taken out of the book, from a security analyst or administrator's point of view, to further secure their systems given that their software may be riddled with flaws? Anything beyond keeping up with their vendor's patches? GM: I hope to convince operations people to intuitively distrust software. They should be equally skeptical of the claims of security software vendors to solve all of their problem with a magic whatzit (like magic crypto fairy dust). Any security person can learn to become aware of programming languages that software is written in, and think through the security implications there. If you want secure software, you cannot just rely on (spurious) claims about security. For example, in order to 'prove' that the software is secure, a security vendor might tout their EAL level. But the Common Criterion is not a fail proof approach. In fact, it is really a "least common denominator" approach to security; because ultimately all it requires is that the vendors demonstrate specific claims that they themselves make about security, such as how well the code was protected while it was being written. But this may have no relationship to real security! That is, some of the vendor claims may not be meaningful to the consumer; and there is really no way to show that any set of claims put together somehow collectively equal "secure software" for all possible situations. This is particularly confusing for the market and its constituent consumers, because the market may not be versed in the subtleties of why various claimsmay not add up to something secure enough. It is at this point that we can circle back to the point of the book---flawed software, and how it is actually exploited. Consider that it can be quite difficult to make code secure when you insist on writing it in C. Only those who need very low level functionality should use a low-level language like C, which provides too much rope for a majority of programmers. Perhaps there should be some sort of a license for writing C! In the end, an administrator or security person should understand that programs written in C are much more likely to be insecure than those written in a modern type safe language like Java or C#. The CIO and/or top operations people can keep this in mind when they decide what software to deploy to solve a particular problem. One way for administrators to deal with software they cannot completely trust is to be very careful to not give software excessive privileges. The manner in which software is installed can make all the difference in the world from a security perspective. In fact, a bad deployment can ruin otherwise pretty darn good software! LS: How difficult is it to get started? How long would it take for today's regular non-security-focused developer or administrator to use these techniques to begin to test and improve the security of the software for which they are responsible? GM: Getting started on software security can be as quick and painless as reading some of the now available books and articles. But getting things going on a really secure footing can be a large undertaking if your organization is big. Consultants like Cigital can sometimes help with this. Of course, even without achieving excellence in software security, there is plenty of value to be found in taking the first steps, such as simply regarding software with the proper dose of suspicion and keeping privileges to the minimum necessary. LS: Your book contains an entire chapter on disassembling andreverse engineering. What is your opinion of security by obscurity? Are open systems less secure because the code is freely available, without having to be disassembled? GM: Firstly, I should say that security by obscurity simply doesn't work, with one exception. That exception is that if you carefully design a new piece of software, have it tested very carefully for security and have it extensively vetted by software security experts, and then don't publish the design, then it does work to make the software harder to exploit. So, security by obscurity only helps if the software is already rock solid. On the other hand, the "open source is more secure" debate is a red herring. All the big software houses, think Microsoft, pay entire armies of people to look at the code. In fact, the economics of the situation are on the side of the closed source guys. Analyzing code for exploitable bugs is a hard job best left to professionals who like to be paid for their work. Because they have deep pockets and can pay people to work hard on software security, Microsoft has greatly improved the security of its code in recent years. Crispin Cowan tried to set up a community-based economy for security analysis of open source called Sardonix. Unfortunately, it didn't work; mostly because there are not enough really qualified people who are interested in doing security analysis for free or for brownie points. In the end it is ridiculous to say that "all bugs are shallow." That's only true for the easy bugs. Some bugs are subtle and simply not easy to detect, even by hordes of people. A related problem...at its core, open source tends to be grown organically. Open source people are feature-oriented, and as we have already discussed, security is not a feature. However, I would like to add that open source has improved from a security perspective, probably just as much as closed source. Partially because of guys like Crispin Cowan and increased scrutiny due to recentattacks. I believe that this improvement was mostly due to the efforts of companies like IBM, and, to a lesser extent, SuSE and Red Hat rather than by some non-economic, non-subsidized means. LS: Your book mentions that black box case testing software that is touted as the final solution for software security is really no panacea. Can you expand upon this point? GM: Black box application testing solutions are not worth much money! Rudimentary dynamic testing that runs 100 canned tests and declares victory is really rather silly. How can you know if the inputs you ended up testing (especially with canned tests) are the ones that would uncover defects? It's true that this sort of testing can help determine "badness." That is if a black-box test suite finds problems, you are in very big trouble indeed. But if all tests are successfully passed, that says little about your real security posture. Don't forget that the basic problem of software security is usually at least as much one of design as of implementation. Black box tests cannot find design flaws (unless they get lucky). A much more useful idea is that of code scanning, looking at source code for potential vulnerabilities. A number of open source scanners can be found (ITS4 and flawfinder to name two), but you have to make sure you understand what the scanner is scanning for in the code. Ask yourself, are you sure that the scanning rules are right? What will they catch, and what might they miss? If you understand what they are looking for and why, code scanning can be very useful. LS: One of the chapters of your book is about the infamous buffer overflow problem. Can you briefly explain to our readers what exactly a buffer overflow is, and why it has become such an issue? GM: Buffer overflows occur because of bad language design (think C) and sloppy code. The best solution is for more software to be written with better languages, like Java and C#, instead of C or C++. Essentially,a buffer overflow happens when information is written over parts of memory that were not intended to hold that information. Think about pouring too much beer in a glass. By overwriting the parts of the memory that hold critical information such as return addresses, an attacker can get an attack payload to execute, with whatever privileges the executing program may have. We explain this in great detail in the book. Direct memory manipulation comes down to us from the days when memory was exceptionally expensive and precious, and had to be used with extreme frugality. But nowadays, there is memory to waste, and programs grab huge swaths of it and rarely release it, treating it as a raw sea of bits. Handling memory properly is something that is beyond the current understanding of many programmers, and the issue is made worse by the use of common, powerful system calls whose security implications may not be well understood by those people using them. LS: In your book, you emphasize the importance of risk analysis to overall software security. Can you please explain this concept to our readers? Why should we not aim for perfectly secure software? GM: We can't just stop using software because its not absolutely provably secure. The only way to make your computer really secure is simply to turn it off. Whenever we add functionality (or turn the machine on), we open the door to security issues. You just have to ask yourself if the functionality you want to utilize is worth the risk you take on. In many cases, the answer will be that it is, but it is critical to realize the basic fundamental nature of this tradeoff. Software security is about minimizing the risk inherent in the additional functionality that software supplies. That's why it is a risk management game. LS: What concrete improvements would you like to see in the field of software design in the future? GM: Less is more in security. Turn off unnecessary functionality and services. Thefeature-oriented set tend to think more is better, but more is less secure. Bloatware is bad. I always ask developers: who plans on having less code at the end of the year as the beginning? Very few of them say they do! Less stuff would be better. Complexity, network-based design, and extensibility (involving mobile code that does stuff on the fly and arrives arbitrarily) are the friends of the attacker. I call these the Trinity of Trouble (also covered in Exploiting Software ). When the Internet toaster is finally available, it will give an attacker the chance to burn your breakfast! LS: What are your future plans? Do you plan on writing any other books/articles? GM: When I write a book, I get to a point where I am absolutely sick of writing, and I say to myself "I'll never write another book again!" And then later, I forget the pain and do it again. I'm still somewhat in the sick of writing phase, but I'm sure I'll soon forget.. Uncover valuable perspectives on application security through our unique dialogue with Gary McGraw regarding vulnerabilities in software.. Software Security, Attack Techniques, Risk Assessment, Code Vulnerabilities, Security Practices. . Brittany Day
Jul 30, 2004
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More