fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

8.6K
active users

#memorysafety

0 posts0 participants0 posts today
#Apple providing the very example of why I think it's a terrible idea to implement #codecs in memory-unsafe languages.

> https://www.macrumors.com/2025/08/20/ios-18-6-2-vulnerability-fix/
> https://support.apple.com/en-us/124925

This would have been impossible in Ada. Or Java. Or even /Swift/ (yes, their own language would have prevented this).

There is no excuse.

#MemorySafety #CVE #Security
MacRumors · Update Now: iOS 18.6.2 and macOS Sequoia 15.6.1 Fix Actively Exploited Vulnerability
More from Juli Clover

Tara from Sovereign Tech Agency and Hugo will be hosting the next 'Memory Safety in the EU' meeting in Amsterdam, on Tue 26 Aug (during ).

The meeting aims to finalise a statement on the importance of memory safety for security by design. This is a joint effort by several European stakeholders to put memory safety on the agenda of both industry and policy makers.

Read more here: tweedegolf.nl/en/blog/160/upda

@tarakiyee
@sovtechfund

tweedegolf.nlUpdate on our advocacy for memory-safety - Blog - Tweede golfWe’ve been raising awareness of the importance of using memory-safe technology to build systems that are truly secure-by-design. We do this alongside our core business, which is to help companies ...

One of our founding directors, Mike Eftimakis, sat down with Akshaya Asokan from Information Security Media Group (ISMG) to explore how CHERI is helping tackle one of cybersecurity’s biggest challenges: memory safety.

CHERI (Capability Hardware Enhanced RISC Instructions) is a hardware-based approach to security, designed to prevent around 70% of today’s common vulnerabilities. Backed by industry leaders and the UK government, we're working to ensure global adoption across the electronics supply chain.

Watch the interview to learn more about:

💠 How CHERI addresses memory safety issues
💠 Common hardware supply chain vulnerabilities
💠 Progress on adoption by chipmakers
💠 Scalability challenges associated with CHERI

🎥 Watch the full interview: bankinfosecurity.com/uks-cheri

The CHERI Alliance is all about bringing the computing world together to adopt CHERI security technology.

We’re a mix of industry partners, open-source contributors, researchers, and governments, all working to make CHERI more accessible and widely used.

Check out who’s already on board: cheri-alliance.org/member/

We’ve got active working groups tackling everything from software porting to system integration and standards - all helping the community adopt and build with CHERI more effectively. Take a look: cheri-alliance.org/who-we-are/

Curious? Keen to get involved? Here’s how to join us: cheri-alliance.org/memberships/

CHERI AllianceMembers Archive – CHERI Alliance

👋 Hey infosec.exchange! We’re the CHERI Alliance — excited to join the community!

🔐 We’re all about CHERI (Capability Hardware Enhanced RISC Instructions) — a powerful hardware-based approach to making memory safety and software security actually enforceable, by design.

💡 CHERI helps stop things like buffer overflows and use-after-free bugs before they cause trouble — with hardware-enforced protections built right into the architecture.

We’re here to:
- Share news about the CHERI community in general
- Talk about what our members are building with CHERI
- Connect with folks who care about deep, meaningful security improvements
Check us out 👉 cherialliance.org

Give us a follow if this sounds like your kind of thing!

"💡 'Memory Safety' is the new 'eat your veggies' of tech that everyone's pretending to care about. USENIX obsesses over it like it's the Holy Grail, but in reality, it's just the bare minimum, like wearing pants to a meeting. 🚫 Spoiler: No one actually reads #governance minutes, ever." 😂
usenix.org/publications/logino #MemorySafety #TechCulture #Humor #BareMinimum #HackerNews #ngated

USENIX · Memory Safety is Merely Table Stakes

“half of tracked security vulnerabilities are not possible in Rust”
- - tpo/core/arti

#oniux
has anyone tested with #Wireshark ?
#audit
But you can verify oniux bash with curl. With

→ oniux bash each time in a new tab in terminal ←

you will have stream isolated the application with a new exit IP (tor circuit), new ephemeral PID.

Nothing like nyx to test without the control port, but a rs network analysis tool could.
#StreamIsolation #MemorySafety #Rustlang #Kernel #tun

but this core project really needs some work (No one knows the name of who they are so impressed with. I've asked.)

The Masked Onion Dance Cascades (whose mutable/static number where)
0xacab.org/leap/tor/onionmasq/

* ipv6 bind all interfaces
not good for mobile, see note here
major.io/p/enable-ipv6-privacy
ipv6 privacy on Kernel level (sysctl tunable)

* private ipv4 (the router did it, not the device!)
reserved address 169.254.42.2

onion0 (as in router not site) interface

→ What are those 56 characters? Actually, a General Public for a Private Specific (undisclosed IP).

A site is not an interface. Not a particular “military number” or Swiss IBAN that can’t be used because there is no RingCT ( iban.com/glossary proxy chains ).

#defcon25
Properties of an onionsite
→ Location Hiding - service IP Address [protected]
xmr . . . onion /onion-services/overview/index.html
* no impersonation, E2EE pub/priv directory and binding
* NAT punching – like TURN server (conf) – P2P past a firewall / AP
en.wikipedia.org/wiki/Traversa

#Rustlang #overflow #MemorySafety #Tor #Android #App #AndroidStudio

Fall for nothing. Period!

Just know and not assume that the military police state is a bunch of cheats and liars.

→ towards Whodora-rs for #mobile

GitLabREADME.md · main · leap / Tor / onionmasq · GitLab0xacab

Day 1 of posting to social media until I get an offensive security research job

First, I’m going to start with what I know – Windows. I need to recreate what I had access to at Microsoft, so that starts by setting up a dev environment and finding a copy of Windows System Internals, perhaps the greatest resource for learning Windows out there. My expertise is in Windows and virtualization, so I’m going to make sure I master those areas.

Next, I don’t think I want to grind coding exercises, but I do need to shake the rust off my coding skills. I think I’m going to start with some HackTheBox challenges and find some CTFs to participate in.

Finally, my long overdue goal: learn Rust. I’m not sure if this will help immediately, as I could choose to improve my knowledge of Python. But Rust was getting more and more popular in the areas of Windows I was tasked with protecting, so I need to learn what all the fuss is about with regards to memory safety.

If anyone is on a similar journey, let’s hold each other accountable in the comments! I will be sure to document any write-ups at blog.maxrenke.com (work in progress).

Continued thread

Memory-related bugs form the majority of impactful vulnerabilities, and eliminating them requires that all stakeholders, from government to industry to academia and technical communities do their part.

As follow up, we’re working towards a second meeting to get more organizations, developers, and users of memory-safe and secure technologies on-board. Please reach out if you’re interested in participating in the next workshop.

Thanks to everyone who joined us!

#MemorySafety

(2/2)