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 4 articles for you...
82
NSAbackdoorsecurity oversightNSA's Criticism On Dual_EC_DRBG Flaw and Its Cryptographic Implications
It was a mistake for the National Security Agency to support a critical cryptographic function after researchers presented evidence that it contained a fatal flaw that could be exploited by US intelligence agents, the agency's research director said.. The comments by NSA Director of Research Michael Wertheimer were included in an article headlined The Mathematics Community and the NSA published this week in a publication called Notices. The article responds to blistering criticism from some mathematicians, civil liberties advocates, and security professionals following documents provided by former NSA subcontractor Edward Snowden showing that the agency deliberately tried to subvert widely used crypto standards. One of those standards, according to The New York Times, was a random number generator known as Dual EC_DRBG, which was later revealed to be the default method for generating crucial random numbers in the BSAFE crypto toolkit developed by EMC-owned security firm RSA.. Concerns arise over NSA's endorsement of the compromised Dual EC_DRBG; essential insights on encryption and safeguarding strategies emerge.. NSA Support of Dual EC_DRBG,Cryptography Security Flaws,Encryption Policy Oversight,Random Number Generation Issues. . Dave Wreski
Jan 15, 2015
•
Government
67
security advisorysecurity issuecryptographic flawGoogle Security Team Exposes Vulnerability in SSL 3.0 Protocol
Google's Security Team revealed on Tuesday that the long obsolete, but still all too used, Secure Sockets Layer (SSL) 3.0 cryptographic protocol has a major security flaw. According to the team's Bodo M. While SSL 3.0 has been succeeded by Transport Layer Security (TLS) 1.0, TLS 1.1, and TLS 1.2, many TLS implementations have continued to be backwards compatible with SSL 3.0 to work with legacy systems for a smoother user experience. The link for this article located at ZDNet Blogs is no longer available. . Microsoft's Cybersecurity Division disclosed a significant vulnerability in the legacy TLS 1.0 framework that remains operational, underscoring potential threats.. SSL Flaw, Legacy Systems, Transport Layer Security. . LinuxSecurity.com Team
Oct 15, 2014
•
Cryptography
67
security advisoryrandom number generatorcryptographic flawRSA BSAFE Toolkit Advisory: Decryption Risk From Weak RNG Influence
Security provider RSA endowed its BSAFE cryptography toolkit with a second NSA-influenced random number generator (RNG) that's so weak it makes it easier for eavesdroppers to decrypt protected communications, Reuters reported Monday. . Citing soon-to-be-published research from several universities, Reuters said the Extended Random extension for secure websites allows attackers to work tens of thousands of times faster when breaking cryptography that uses the Dual EC_DRBG algorithm to generate the random numbers that populate a specific cryptographic key. . Investigations show that the BSAFE toolkit from RSA relies on a weak RNG influenced by the NSA, jeopardizing the integrity of secure communications.. BSAFE Cryptography, Random Number Generation, Security Flaw, Decryption Risk. . LinuxSecurity.com Team
Apr 03, 2014
•
Cryptography
67
cyber threatsapplication securitysecurity riskASP.Net Cryptographic Flaws Impacting Online Banking Security
Flaws in the way web applications handle encrypted session cookies might leave online banking accounts open to attack. The security risk stems from a cryptographic weakness in web applications developed using Microsoft's ASP.Net framework. . ASP.Net uses the US government-approved AES encryption algorithm to secure the cookies generated by applications during online banking sessions and the like. However implementation flaws in how ASP.NET handles errors when the encrypted data in a cookie has been modified give clues to a potential attacker that would allow him to narrow down the possible range of the keys used in an online banking session. Attacks based on this weakness might allow a hacker to decrypt sniffed cookies or forge authentications tickets, among other attacks. The link for this article located at The Register UK is no longer available. . Weaknesses in ASP.Net’s management of encrypted cookies could potentially put online banking at risk of cyber threats.. AES Encryption, Online Banking Threats, Application Security, Cybersecurity Risks, Cryptographic Vulnerabilities. . LinuxSecurity.com Team
Sep 14, 2010
•
Cryptography
83
security advisoryDebianUbuntuDebian and Ubuntu Security Advisory: Key Forgery Risks and Solutions
A recently disclosed vulnerability in widely used Linux distributions can be exploited by attackers to guess cryptographic keys, possibly leading to the forgery of digital signatures and theft of confidential information, a noted security researcher said today. As a tie-in to previous stories posted about Debian's SSL flaws, this article reveals reknown security expert HD Moore's views on the situation. He also provides suggestions on how to properly respond to the flaw and gives advice on whom should be concerned and what patches should be applied.. The link for this article located at Computer World is no longer available. . A recognized specialist examines critical weaknesses present in Ubuntu and Debian systems, offering strategies for remediation and highlighting potential risks.. Debian Security, Ubuntu Threats, Cryptographic Vulnerabilities, Digital Signature Forgery. . LinuxSecurity.com Team
May 16, 2008
•
Hacks/Cracks
67
security advisorygnupgcriticalGnuPG: Key Compromise Advisory and Immediate Revocation Recommended
Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds.. . .. Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GnuPG's ElGamal signing keys compromised ========================================== Summary ======= Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds. Please *take immediate action and revoke your ElGamal signing keys*. Furthermore you should take whatever measures necessary to limit the damage done for signed or encrypted documents using that key. Please do not send private mail in response to this message as I won't have the time to catch up with all the messages. The mailing list gnupg-users at gnupg.org is the best place to discuss this problem (please subscribe first so you don't need moderator approval [2]). Note that the standard keys as generated by GnuPG (DSA and ElGamal encryption) as well as RSA keys are NOT vulnerable. Note also that ElGamal signing keys cannot be generated without the use of a special flag to enable hidden options and even then overriding a warning message about this key type. See below for details on how to identify vulnerable keys. This message is signed using the usual GnuPG distribution key[1]. I apologize forthis severe bug and all the problems resulting from it. Background: =========== For historic reasons [3], GnuPG permits creating ElGamal keys which are usable for both encryption and signing. It is even possible to have one key (the primary one) used for both operations. This is not considered good cryptographic practice, but is permitted by the OpenPGP standard. It was not anticipated that these keys would still be used for signing because they have several disadvantages: The signature is much larger than a RSA or DSA signature, verification and creation takes far longer and the use of ElGamal for signing has always been problematic due to a couple of cryptographic weaknesses when not done properly. Thus I have always dissuaded people from using ElGamal keys for signing; however they are still used and about 200 keys per year are generated and uploaded to the keyservers. In January 2000, as part of version 1.0.2, the GnuPG code was changed to create ElGamal keys which work more efficiently for encryption (selecting a smaller x secret exponent and using a smaller k for encryption). While making this change the problem with signing keys was accidentally introduced: the same small k for encryption was also used for signing. This can be used for a cryptographic attack to reveal the private key (i.e. the secret exponent x) if a signature made using that key is available. Such a signature is always available for primary ElGamal keys because signatures created with that key are used to bind the user ID and other material to the primary key (self-signatures). Even if the key was never used for signing documents it should be considered compromised. Note that this weakness does not apply to the far more common encrypt-only (type 16) ElGamal key as GnuPG does not permit signatures to be issued by this key type. Only the ElGamal sign+encrypt key (type 20) is affected and then only when used to make a signature with a GnuPG version 1.0.2 or later. Impact: ======= All ElGamal sign+encrypt keys (type 20)generated with GnuPG 1.0.2 or later must be considered compromised. Keys generated and used only with prior versions might still be safe but should ideally be revoked too. Note that even if an ElGamal sign+encrypt key was generated before GnuPG 1.0.2, using that key in GnuPG 1.0.2 or later to issue signatures will still compromise the key. Again, ElGamal encrypt-only keys (type 16) from any version of GnuPG are *not* affected. Solution: ========= Do not use *ElGamal sign+encrypt keys (type 20)*. Revoke all those keys immediately. Consider all material signed or encrypted with such a key as compromised. Forthcoming GnuPG versions will remove the ability to create such keys and the ability create ElGamal signatures. How to detect ElGamal type 20 keys: =================================== We have to distinguish between two cases: The primary key is ElGamal sign+encrypt versus just a subkey is ElGamal sign+encrypt. The first case requires immediate attention, like this one: $ gpg --list-keys xxxxxxxx pub 2048G/xxxxxxxx 2001-xx-xx Mallory such a key might be followed with additional "uid", "sig" or "sub" lines. Here an ElGamal sign+encrypt key is used and very likely created with GnuPG > = 1.0.2. The capital letter "G" indicates a ElGamal sign+encrypt key. REVOKE such a key immediately. The second case is about subkeys. Here is an example: $ gpg --list-keys 621CC013 pub 1024D/621CC013 1998-07-07 Werner Koch uid Werner Koch uid Werner Koch sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01] sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06] sub 1536R/23D2A63D 2002-07-30 [expires: 2003-12-31] This my usual working key, which is a standard GnuPG key with some additional subkeys added over time. It is a good example because one subkey was created as type 20 signing and encrypt ElGamal key. It is the second subkey: sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06] The capital letter "G" denotes such anpossible compromised subkey whereas the first subkey: sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01] is a standard encryption-only subkey as indicated by the small letter "g". That key is not affected. The keys denoted with this capital letter "G" should be REVOKED unless you are definitely sure those subkeys were never used to create a signatures with GnuPG > = 1.0.2. How to revoke a key: ==================== To create a revocation certificate for the entire key (primary and all subkeys), you do: gpg --gen-revoke your_keyid > foo.rev If you have lost access to your passphrase, hopefully you have a pre-manufactured revocation certificate (either on a floppy or printed on a sheet of paper) which you may the use instead of the above command. This revocation certificate should then be imported into GnuPG using: gpg --import mykey.asc gpg --keyserver subkeys.pgp.net --send-keys your_keyid If your primary key is not an ElGamal key, you might need to revoke a subkey. Note again that only type 20 ElGamal keys (denoted by a capital letter "G") require revocation - the standard ElGamal encrypt-only key (small g) is perfectly fine. Use gpg's edit command like this: $ gpg --edit-key xyzxyzxy The key listing will be shown. Select the subkey you want to revoke, using the command "key 2" (or whatever subkey it is) and then enter the command "revkey" and follow the prompts. Continue then with an export as described above. How many keys are affected? =========================== I can't tell for sure. According to the keyserver statistics, there are 848 primary ElGamal signing keys which are affected. These are a mere 0.04 percent of all primary keys on the keyservers. There are 324 vulnerable subkeys on the keyservers, too. Some of the subkeys might have never been used for signing because for some time in the past GnuPG created the encryption subkey as type 20 but didn't used it for signing because the DSA primary key was used instead. It is better to revoke such keysnevertheless. Note again that the standard configuration of GnuPG does not allow creating the vulnerable sign+encrypt ElGamal keys and that neither DSA (type 17), RSA (type 1) nor ElGamal encrypt-only keys (type 16) are affected. Thanks ====== Phong Nguyen [4] analyzed the implementation of GnuPG's cryptographic parts and found this vulnerability. He also developed actual code to mount the attack and was so kind to give me enough time to have a look at his paper and to gather a list of known type 20 keys owners. I am really sorry for this, Werner [1] To get a fresh key you might want to consult the keyservers or get it from using "finger wk at g10code.com" or "finger dd9jn at gnu.org". [2] See http://lists.gnupg.org/mailman/listinfo/gnupg-users . [3] The patent status of DSA was not clear when I started to write GnuPG back in 1997. [4] Working at the French National Center for Scientific Research and the Ecole normale superieure: https://www.di.ens.fr/~pnguyen/ . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xavwaLeriVdUjc0RAquhAJ9crSJ2j8EbqaAnbJGoXBsgERPLaACePwcP 70laYWsyhXkzVgqL2X4ELVk= =xGWG -----END PGP SIGNATURE----- . An urgent alert has been raised by Phong Nguyen regarding a severe vulnerability in GnuPG that jeopardizes the integrity of ElGamal signing keys. Swift intervention is essential!. GnuPG Security, ElGamal Key Risk, Cryptographic Attack, Key Revocation. . LinuxSecurity.com Team
Nov 27, 2003
•
Cryptography
67
security advisorybanking securitycryptographic flawLondon High Court: Cambridge Researchers Gagged Over ATM Security Flaws
The High Court in London has imposed an injunction on Cambridge University security experts who claim to have uncovered serious failings in the system banks use to secure ATM PIN codes. . . .. The High Court in London has imposed an injunction on Cambridge University security experts who claim to have uncovered serious failings in the system banks use to secure ATM PIN codes. The gagging order, preventing public disclosure of cryptographic vulnerabilities, was made at the request of CitiBank and Diners' Club against experts due to testify in a 'phantom withdrawal' case to be heard in the South African High Court next month. South African couple Anil and Vanita Singh say that £50,000 withdrawn through the Diners' Club account through British ATMs in March 2000 was never made by them. Diners Club say that its systems are secure, so the money must have been withdrawn by the Singhs. . The High Court in London has imposed an injunction on Cambridge University security experts who clai. court, london, imposed, injunction, cambridge, university, security, experts. . LinuxSecurity.com Team
Feb 24, 2003
•
Cryptography
67
security advisorythreat assessmentresearchIBM: Evaluate Cryptographic Security Breach After Student Findings
An independent expert has backed two Cambridge University students' claims to have uncovered a flaw in a key IBM cryptographic coprocessor that is at the heart of some of the world's most secure systems. IBM has been warned not to dismiss . . . . An independent expert has backed two Cambridge University students' claims to have uncovered a flaw in a key IBM cryptographic coprocessor that is at the heart of some of the world's most secure systems. IBM has been warned not to dismiss the two Cambridge University research students, who claim to have developed a system to hack bank security codes and potentially obtain thousands of PIN numbers. IBM had said the students' method could only work in laboratory conditions and that a bank's physical security measures would prevent attack. However, Dr Nicko van Someren, chief technical officer of Ncipher - one of the world's largest suppliers of cryptographical engines to financial institutions - told CW360.com: "This is a significant security breach. Security managers should be worried but not panicking." The link for this article located at ComputerWeekly.com is no longer available. . An independent expert has backed two Cambridge University students' claims to have uncovered a flaw . independent, expert, backed, cambridge, university, students', claims, uncovered. . LinuxSecurity.com Team
Nov 14, 2001
•
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