Sign inCreate account
mastodon.sdf.org is part of the decentralized social network powered by Mastodon.
"I appreciate SDF but it's a general-purpose server and the name doesn't make it obvious that it's about art." - Eugen Rochko

Administered by:

Server stats:

2.4K
active users
Learn more

mastodon.sdf.org: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.1.24

*
Marco Ivaldi

A couple of days ago, I unearthed my first #computer, an #MSX straight from the ‘80s. It was lost in some box in the basement for who knows how long. Just feeling its power switch gave me the goosebumps…

This discovery came after sharing my hacker’s origin story with Nic Fillingham and Wendy Zenone in a new episode of Microsoft’s #BlueHat #Podcast.

thecyberwire.com/podcasts/the-

Join us while we chat about my first-ever #CVE, overlooked #vulnerabilities that continue to pose significant risks today, #ActiveDirectory and #password security, my unexpected journey into #bugbounty hunting and my involvement in the #ZeroDayQuest, how to learn new things, mentorship and positive leadership, and of course pineapple pizza 🍍🍕

This is how you make a hacker
SecuriLee🇨🇭

🔐 The Evolution of CVEs: From Humble Beginnings to Record-Breaking Growth 🔐

Since 1999, the Common Vulnerabilities and Exposures (CVE) system has transformed how the cybersecurity community identifies, tracks, and responds to software vulnerabilities. What started as a small, standardized list of just over 300 vulnerabilities has exploded into a global, indispensable resource with nearly 40,000 CVEs logged in 2024 alone - a staggering 38% increase from the previous year!

In my latest article, I explore the fascinating journey of CVEs through three pivotal eras:

1️⃣ The Formative Years (1999–mid-2000s): Establishing a common language for vulnerability identification.

2️⃣ The Expansion and Integration Years (2005–2016): Building robust infrastructure, standardizing severity scoring, and integrating CVEs into enterprise security workflows.

3️⃣ The Acceleration Era (2016–Present): A surge driven by automation, open-source growth, and expanded reporting authorities, leading to unprecedented annual CVE volumes.

Looking ahead, 2025 is forecasted to break new records with an estimated 49,000 CVEs-a 22.5% jump over 2024. This relentless growth underscores the increasing complexity of software ecosystems and the critical need for proactive vulnerability management.

If you want to understand how the CVE system evolved and why staying ahead of this expanding threat landscape matters more than ever, check out the full article here: ciso.pm/the-history-of-cves/

#Cybersecurity #Vulnerabilities #CVE #InfoSec #RiskManagement #SecurityTrends #CyberRisk

A massive amount of CVEs rated 9.8 flying about
Tom Eston :verified:

In the latest episode of the @sharedsecurity podcast we discuss the challenges facing the cybersecurity industry as we analyze government funding decisions impacting the CVE program.

We also discuss the executive order targeting former CISA Director Chris Krebs.

Watch on YouTube:
youtu.be/y7RZdLYSXSc

Listen and subscribe to the podcast!
sharedsecurity.net/2025/04/28/

sharedsecurity.net/subscribe

#podcast #cisa #cve #cybersecurity

Felix Palmen :freebsd: :c64:

Revisiting #async / #await in #POSIX C, trying to "add some #security" 🙈

Recap: Consider a classic #reactor-style service in C with a #threadpool attached to run the individual request handlers. When such a handler needs to do some I/O, it'll have to wait for its completion, and doing so is kind of straight forward by just blocking the worker thread executing the job until whatever I/O was needed completes.

Now, blocking a thread is never a great thing to do and I recently tooted about an interesting alternative I found: Make use of the (unfortunately deprecated) POSIX user context switching to enable releasing the worker thread while waiting. In a nutshell, you create a context with #makecontext that has its own private #stack, and then you can use #swapcontext to get off the thread, and later again to get back on the thread. A minor issue is: It must be the *same* thread ... so you might have to wait until it completes something else before you can resume your job. But then, that's probably okayish, you can make sure in your job scheduling to only use worker threads with awaited tasks attached when no other thread is available.

In my first implementation, I just used #malloc to create a 64kiB private stack for each thread job. That's perfectly fine if you can guarantee your job will never consume more stack space, AND it won't have any vulnerabilities allowing some attacker to mess with the stack. But in practice, especially for a library offering this async/await implementation, it's nothing but a wild #CVE generator.

So, I now improved on that:

* Allocate a much larger stack of now 2MiB. That alone makes issues at least less likely. And on a sane modern OS, we can still assume pages will only be mapped "on demand".
* Only allocate the stack directly before running the thread job, and delegate allocation to some internal "stack manager" that keeps track of all allocated stacks and reuses them, only freeing them on exit. This should avoid most of the allocation overhead.
* If MAP_ANON / MAP_ANONYMOUS is available, use #mmap for allocating the stack. That at least gives a chance to stay away from other allocations ....
* But finally, if MAP_STACK is available, use this flag! From my research, #FreeBSD, #OpenBSD and #NetBSD will for example make sure there's at least one "guard page" below a stack mapped with this flag, so a stack overflow consistently takes the SIGSEGV emergency exit 😆. #Linux knows this flag as well, but doesn't seem to implement such protection at this time ... 🤔

#C #coding

Vitex

glibc (2.41-7) unstable; urgency=medium

Starting with glibc 2.41, shared libraries requiring an executable stack
cannot be dynamically loaded through the #dlopen mechanism from a binary that
does not require an executable stack. This change aims to improve security,
as the previous behavior was used as a vector for RCE (#CVE-2023-38408).
Attempting to do so will result in the following error:

cannot enable executable stack as shared object requires: Invalid argument

While most libraries generated in the past 20 years do not require an
executable stack, some third-party software still need this capability. Many
vendors have already updated their binaries to address this.

If you need to run a program that requires an executable stack through
dynamic loaded shared libraries, you can use the glibc.rtld.execstack
tunable:

Glibc6_TUNABLES=glibc.rtld.execstack=2 ./program

-- Aurelien Jarno <aurel32@debian.org> Sun, 13 Apr 2025 14:41:11 +0200

#Debian #Changelog #GLibC #Security #Linux

ExploreLocalFederated
About

Trending now

#springbreakasongorpoem46 people in the past 2 days
#superstitioustvshows75 people in the past 2 days
#meermittwoch58 people in the past 2 days