Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
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 news
We found -3 articles for you...
77
security advisorybuffer overflowdesign flawCORE Advisory: 20020409 Critical Stack Protection Issues Explored
"Stack shielding" software have been developed on the promise of preventing exploitation of buffer overflow vulnerabilities that make use of the stack smashing techniques. We discovered that all of them present basic design limitations as well as some implementation flaws.. . . . "Stack shielding" software have been developed on the promise of preventing exploitation of buffer overflow vulnerabilities that make use of the stack smashing techniques. We discovered that all of them present basic design limitations as well as some implementation flaws. Date: Tue, 23 Apr 2002 19:44:51 -0300 From: "[iso-8859-1] Ivn Arce" To: BUGTRAQ@ Cc: core.lists.vulnwatch@corest.com Subject: CORE-20020409: Multiple vulnerabilities in stack smashing protection technologies CORE SECURITY TECHNOLOGIES Advisory Multiple vulnerabilities in stack smashing protection technologies Date Published: 2002-04-23 Last Update: 2002-04-23 Advisory ID: CORE-20020409 Bugtraq ID: Non-assigned yet CVE CAN: Non-assigned yet Title: Multiple vulnerabilities in stack smashing protection technologies. Class: Design limitation, Implementation flaw Remotely Exploitable: Yes Locally Exploitable: Yes Vendors contacted: 2002-04-15 - Immunix: Yes - Microsoft: Yes - Stack Smashing Protection (SSP) formerly ProPolice: Yes - StackShield: No, all attempts to notify the maintaners via email failed. No other contact information was found (the website has not been updated since January 8th, 2000). Release Mode: COORDINATED RELEASE Vulnerability Description: In the past years, several technologies (in the form of softwarepackages) have been developed to protect programs against exploitationof buffer overflow vulnerabilities. These technologies aim at detectingand preventing the execution of hostile code that takes advantage ofsoftware security vulnerabilities by overwriting a critical portionof a running program's memory known as the stack. The techniques used to exploit this type of vulnerabilities havebeendiscussed at length in the past years and, although they have been usedfor years in malicious code, notably the famous Robert T. Morris worm in1988 [1], were initially introduced to the security community at large inthepioneering articles "Smashing the stack for fun and profit" [2] writen byAleph1and "How to write buffer overflows" by Mudge.[3] Technologies to detect and prevent "stack smashing" exploit code werepresented thereafter, notably at the 1998 USENIX Security conference [4]. "Stack shielding" software have been developed on the promise of preventingexploitation of buffer overflow vulnerabilities that make use of the stacksmashing techniques. Several other techniques to exploit buffer overflows that DO NOT make useof stack overwriting or code execution on the stack have be presentedduring the past years. Techniques that exploit vulnerabilities by overwriting or otherwise abusingother memory portions of a running program are described in Solar Designer's"Getting around non-executable stack (and fix)" [5], "Advancedreturn-into-lib(c)exploits(PaX case study)" [6] and "w00w00 on Heap Overflows" [7]. However, for the purpose of this advisory we will focus on the stackprotectionmechanisms and claim the current technologies do not provide adecuateprotection: Stack shielding protections have been missunderstood, they only protect aparticular type of stack smashing exploitation, namely return addressoverwrites,NOT generic stack smashing attacks as they claim. This has been demostrated in the past, as in "Bypassing StackGuard AndStackShield" [8] and "Vulnerability in ImmuniX OS Security Alert:StackGuard1.21 Released" [9] We studied the three most visible "stack shielding" technologies: -Wirex StackGuard () and -StackShield ( (https://www.angelfire.com/sk/stackshield/download.html ) -Stack Smashing Protection (SSP, formerly ProPolice), from Hiroaki Etoh (https://www.ibm.com/us-en) As well as the recently introduced /GS stack protecting mechanismincorporated into Microsoft's Visual C++.NETas part of the Visual Studio.NETproduct family. Information about the feature and details on how it worksare availableat: https://www.bing.com/ We discovered that all of them present basic design limitations as well assome implementation flaws. Our conclusion is that although "stack shielding" technologies present avaluable mean to prevent execution of certain forms of malicious code, thosetechnologies should not be thought as a solution to the problem of bufferoverflowvulnerabilities in general and not even as a solution to some simple stacksmashingtechniques used to exploit those vulnerabilities. Stack shielding mechanims do not suffice to ameliorate the effects of badlywritten software and could give a false sense of security of devastatingeffects, if notconsidered as part of a general security strategy that includes securedesignmethodologies, secure programming practices, strict and well definedsecurity testingprocesses and the implementation of fixes and patches as well as the use ofad hoctechnologies to prevent exploitation of existing vulnerabilities, publicyknown or otherwise. Vulnerable Packages: StackShield up to, and including, v0.7-beta is vulnerable to #1, #3 and#4 StackGuard 1.2 and 2.0.1 (included in Immunix 7.0) is vulnerable to all the described methods. StackGuard 1.21 is not vulnerable to #2 Other StackGuard versions were not tested and are suspected to be vulnerable as well. Programs compiled with Microsoft Visual C++.NET /GS compiler switch are still exploitable by using techniques described in problem #1. Exploitation using #2, #3 and #4 is only possible if the attacker can guess or bruteforce the correct value of the "cookie", the existence ofheuristics for doing that are not in the scope of this advisory. SSP (ProPolice) is NOT vulnerable to any of the described exploitationmethods. Solution/Vendor Information/Workaround Wirex's Immunix StackGuard. Wirex offical response is: The upcoming next release of StackGuard,version 3.0 fixes problems #2, #3 and#4 by moving the terminator canary to a position between the frame pointer and all local variables. Problem #1 is not part of StackGuard's threat model, that is StackGuard is not designed to protect against exploitation before the vulnerable function exits. Microsoft Visual Studio.NET /GS Refer to Microsoft's white paper describing the design and implementation of the /GS switch: https://www.bing.com/ StackShield N/A ProPolice/SSP SSP is NOT vulnerable to any of the problems described. Credits: This vulnerabilities were discovered and researched by Gerardo Richartefrom CORE Security Technologies. Pionering work and ideas were introducedby Richarte and many others (see the references section) in variousinformationsecurity mailing lists and publications as far back as 1999.We wish to thank Crispin Cowan and Seth Arnold from Wirex (Immunix) fortheir quick response addressing this report. Technical Description - Exploit/Concept Code As stated previously, we have identified two basic design limitations inthe current stack smashing technologies: First, they only protect data located in memory "above" the firstsafeguarded address. Second, (and we think this is a more serious limitation) they only checkfor attacks after the called vulnerable function finishes, right beforereturning from it so exploitation is possible BEFORE exiting the vulnerable function. In addition to this, StackGuard and StackShield have an implementationflaw: They They protect the stack starting at the return address, leaving the savedframe pointer unprotected. In our study we found four different tricks to bypass stack smashingprotections, the first one is an extension of that described in thepreviously referedarticles and is a direct consecuence of design limitations. The other threeresult fromabusing frame pointer overwrites, and may be corrected introducing somechangesin the protection mechanisms. Control of function's arguments In [8] and [9] a method to exploit stack based buffer overflows onstackprotectedprograms is presented. In the example, a local pointer is used to write toarbitrarymemory locations within the program's memory space. This technique can beextendedto exploit the fact that in standard C compiled programs, function argumentsare locatedin the stack at "higher" addresses than the return address: lower addresses [ local variables ] [ saved frame pointer ] [ CANARY (0x000dff0a) ] [ return address ] [ function's arguments ] higher addresses Controlling functions arguments can effectively turn a stack protectedfunction into anexploitable program by turning the arguments into a"write-anything-anywhere" primitive.Once the attacker has the ability to "write anything, anywhere" it istrivial to bypass stack protection mechanisms. The following program will function as proof of concept code: gera@vaiolent:~src/sg/tests$ cat > sg1.c
Nov 03, 2023
•
Server Security
67
security advisorycommand injectiontlsSTARTTLS Command Injection Threats in SMTP: Insights from Venema
Vulnerabilities in implementations of the STARTTLS protocol for establishing an encrypted TLS connection could allow commands to be injected into a connection. According to a description by the discoverer of the problem, Postfix developer Wietse Venema, the key point is that commands are injected into the connection before it has been secured/encrypted, but are only executed once the secure connection has been established.. Venema illustrates the problem with an example involving securing SMTP with TLS. A client sends "STARTTLS\r\n"; using a man-in-the-middle attack an attacker changes this to "STARTTLS\r\nRSET\r\n". The client and server then establish a TLS connection. The server now regards the injected RSET command that was added during the unprotected phase as if it has been transferred subsequent to the TLS connection being established. The RSET command in this example is relatively innocuous as it is a harmless protocol reset command, but other commands could be injected in a similar fashion. The link for this article located at H Security is no longer available. . Postfix engineer Venema elaborates on the STARTTLS vulnerability opening doors for command injection prior to establishing TLS. Discover the potential consequences.. STARTTLS, Command Injection, SMTP Security, TLS Protocol, Encryption Risks. . LinuxSecurity.com Team
Mar 08, 2011
•
Cryptography
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