1. 2

Without looking at the (unavailable?) patch, it seems like the proposed solution is to migrate away from ASLR to ASR. ASLR uses pre-calculated randomized deltas (calculated at image load time (aka, execve)) to simply shift the different parts of an executable image. ASR does away with the deltas.

1. 2

Correction: the patches are available. I just needed to stop being lazy. ;)

Patches are here: https://github.com/blackzert/aslur/tree/master/patches

1. 1

The Strava heatmap OPSEC failure gave me an idea. Is anyone maintaining an aggregated list of OPSEC failures and successes? I’d be interested in publishing/maintaining such a list if one doesn’t already exist.

1. 2

Have you looked into ZeroNet?

1. 3

I have, but it requires a Bitcoin wallet and downloading a binary. Whatever I end up using needs to be simple and accessible enough for me to convince at least some of my friends to use.

It needs to be the kind of thing where privacy is inside the Trojan Horse. The experience is great, and if you happen to care about it, it also has privacy. It can’t be the kind of thing where the user has to jump through hoops.

1. 3

ZeroNet doesn’t require a bitcoin wallet. In fact it doesn’t use bitcoin at all. I don’t know why this became a thing. Maybe because ZeroNet site addresses are valid bitcoin addresses, and you can import the private key for a site into bitcoin if you want, then people can send coins to your site address and you can receive them. I don’t know of anyone who actually does this though.

You don’t need to download a binary. It’s written in Python and open source. Clone the repository and run if you want. If you have non-tech friends there are “bundles” which contain everything needed to run and stay updated.

I wrote about using their decentralized microblogging system on a post about ZeroMe if you want to look at it further.

1. 2

In fact it doesn’t use bitcoin at all.

Huh, that’s new to me. I had assumed it was more deeply tied in because the front page mentions bitcoin prominently, and even uses the phrase “your bitcoin wallet” (which seems to imply I have one). Although on closer reading, to be fair, it just says that it uses “the same cryptography as” my bitcoin wallet, not the actual wallet. There’s also another blurb saying “Decentralized domains using Namecoin cryptocurrency”, which added to my impression that I probably needed to be deep into the cryptocurrency scene to use this.

I’ll give it another look!

1. 12

Downloading and installing (even signed) packages over unencrypted channels also allows an attacker with the ability to inspect traffic to be able to take an inventory of the installed software on the system. An attacker could use that to his/her advantage by knowing which software, and its vulnerabilities, is installed. The attacker then has the exact binary and can replicate the entire system, tailoring exploits to the inventory on the target system.

1. 21

They cover this in the linked page; they claim there’s such a small number of packages that merely knowing the length of the ciphertext (which, of course, HTTPS can’t hide) is enough to reliably determine which package is being transmitted.

Perhaps doing it over HTTP2, so you get both encryption and pipelining, would get you sufficient obfuscation, but HTTPS alone doesn’t.

1. 2

I’m not sure how http2 helps. You still can generally take a look at traffic bursts and get an idea of how much was transferred. You’d have to generate blinding packets to hide the actual amount of traffic that is being transferred, effectively padding out downloads to the size of the largest packages.

1. 2

But figuring out which packages would require solving the knapsack problem, right? Instead of getting N requests of length k_i, you get one request of length \sum k_i. Although, now that I think about it, the number of packages that you download at once is probably small enough for it to be tractable for a motivated attacker.

2. 1

True. Given that each package download is its own connection, it wouldn’t be too difficult for an attacker to deduce which package is being downloaded given the size of the transmitted encrypted data. The attacker would need to keep a full mirror of the package repo (disk space is cheap, so plausible). I wonder if the same would apply to package repos served over Tor Onion Services.

1. 1

Why would I apply the patches against this on my home computer? One userspace process can steal from another userspace process? That’s just me and my one user.

1. 5

1. 1

Ah yes, fair enough.

1. 7

Does OpenBSD mitigate Meltdown?

1. 2

Not right now. I’m sure someone at OpenBSD is looking at it, though.

1. 1

I’m curious if all the randomization protects machines.

1. 8

/u/lattera is correct. From the Meltdown paper:

In 2013, kernel address space layout randomization (KASLR) had been introduced to the Linux kernel (starting from version 3.14) allow- ing to randomize the location of the kernel code at boot time. However, only as recently as May 2017, KASLR had been enabled by default in version 4.12. With KASLR also the direct-physical map is randomized and, thus, not fixed at a certain address such that the attacker is required to obtain the randomized offset before mount- ing the Meltdown attack. However, the randomization is limited to 40 bit.

Thus, if we assume a setup of the target machine with 8 GB of RAM, it is sufficient to test the address space for addresses in 8 GB steps. This allows to cover the search space of 40 bit with only 128 tests in the worst case. If the attacker can successfully obtain a value from a tested address, the attacker can proceed dump- ing the entire memory from that location. This allows to mount Meltdown on a system despite being protected by KASLR within seconds.

Emphasis my own.

1. 2

No. Neither KARL from OpenBSD nor KASLR from NetBSD would mitigate either Meltdown or Spectre in the slightest. Meltdown and Spectre are due to bugs in the underlying hardware.

1. 1

But how will you know which addresses to scan? How long would it take to scan a 64 bit address space?

1. 7

The kernel virtual address space is MUCH more limited than 64 bits. Kernels are extremely leaky, too. And large. All you have to do is guess around the address space you think the kernel might be mapped at and wrok from there.

Additionally, KARL doesn’t randomize the address space. It randomizes the objects placed within it. So you’re still dealing with the same address space. Just start leaking data and parse it until you get something that makes sense.

On a lot of OSes, you might see some addresses that remain static in the kernel (VDSO, interrupt handlers, page tables, etc). Especially with physical address space instead of virtual.

Essentially, no matter what, there’s not enough entropy in the kernel address space to matter. And even if there was, these are hardware bugs, not software.

This is exactly why Linux is doing KPTI. It already had KASLR and that’s not effective. Randomizing the kernel address space, no matter how it’s done (KARL, KASLR, KASR) is worthless and ineffective.

1. 6

I wonder if an attacker could escalate privileges and/or achieve ring0 write access by combining Row Hammer with Meltdown and/or Spectre.

1. 2

It occurs to me that, in a real and practical sense, one of the biggest exploit mitigations we have at our disposal is the inaccessibility of hardware and kernel architecture knowledge due to complexity. The real reason the systems I’m in charge of aren’t compromised right now (to my knowledge) is because it’s complicated and I’m not on the radar of the few people who can do it.

1. 25

Spectre PoC: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 (I had to inline one #DEF, but otherwise works)

1. 5

I’ve tested it with some success on FreeBSD/HardenedBSD on an Intel Xeon. It works on bare metal, but doesn’t work in bhyve.

1. 4

oh god that runs quickly. terrifying.

1. 3
$./spectre Reading 40 bytes: Illegal instruction (core dumped)  That was kinda disappointing. (OpenBSD on Hyper-V here.) 1. 10 It worked for me on OpenBSD running on real hardware. 1. 1 That was kinda disappointing. (OpenBSD on Hyper-V here.) perhaps it was the cache flush intrinsic. 2. 2 I’m impressed how easy it is to run this PoC - even for somebody who didn’t do C programming for years. Just one file, correct the line #define CACHE_HIT_THRESHOLD(80) to #define CACHE_HIT_THRESHOLD 80 then compile: gcc -O0 -o spectre spectre.c run: ./spectre and look for lines with “Success: “. I am wondering if there is some PoC for JavaScript in the Browser - single HTML page with no dependencies containing everything to show the vulnerability? 1. 2 I’ve been playing quickly with the PoC. It seems to work just fine on memory with PROT_WRITE only, but doesn’t work on memory protected with PROT_NONE. (At least on my CPU) 1. 6 It’s nice to see that this vulnerability is fully mitigated in HardenedBSD with: 1. PaX ASLR 2. PaX NOEXEC 3. PIE 4. RELRO + BIND_NOW 1. 4 Asking as someone does not actively following FreeBSD anymore: why doesn’t FreeBSD have ASLR or use these changes from HardenedBSD? 1. 2 That’s a tough question, but I think it boils down to different priorities of FreeBSD developers and clashing personalities. I’m @lattera can speak about that. 1. 2 You’ll need to ask FreeBSD that question. I cannot and do not speak on their behalf. 1. 1 How does one suggest a thread merge? It’s already covered in this thread: https://lobste.rs/s/drbamo/huge_dirty_cow_cve_2017_1000405 1. 6 It’s nice to see independent verification of exploit mitigations, given that the verification procedure is correct. On HardenedBSD, we have five deltas on 64-bit systems: 1. mmap 2. Stack 3. PIE base 4. VDSO 5. mmap(MAP_32BIT) On 32-bit systems, we only use the first four deltas. I say that loosely as HardenedBSD is disinterested in 32-bit systems and does not actively develop or test on any 32-bit system. We don’t provide installation media nor packages for 32-bit systems. Personally, I’d like to see 32-bit systems die. The author makes no mention of the fact that multiple deltas are used. In fact, the author infers that only a single delta is used: It adds a random offset to the virtual memory layout of each program HardenedBSD is the only BSD that is able to introduce 41 bits of entropy into the stack on amd64. When dealing with stack-based buffer overflows (as discussed in the paper), the stack delta is what’s most important. It’s also important that the deltas are maintained separate from each other and cannot be correlated with each other. Meaning, the value of the mmap delta is not somehow connected to the value of the stack delta. Since HardenedBSD inherited jemalloc from its upstream, FreeBSD, you’ll notice that heap entropy is somewhat less. Using a different heap implementation, like OpenBSD’s, has the potential to increase heap entropy. HardenedBSD is simply modifying the hint passed into the virtual memory (VM) subsystem. As such, the VM subsystem can further modify the hint to account for superpages or other constraints. We deliberately chose this method in order to not break superpage support. However, it does come at a cost of potentially reducing entropy. There’s still room for improvement. If we hooked directly into the VM subsystem, we could likely find ways to increase entropy. Doing so would come at a cost of performance, though, due to increased locking in contentious sections of code. To increase heap entropy, like mentioned above, we could switch to a different heap implementation (preferably OpenBSD’s). The paxtest application provides better insight into the deltas than this whitepaper. 1. 12 No VPN provider is going to go to jail over the illicit use of its services by its users. It’s quite possible that prior to the FBI knocking on their door, they didn’t keep logs. I’d imagine the following scenario: 1. FBI investigates, sees the suspicious traffic coming from PureVPN 2. FBI gets a warrant/subpoena for PureVPN 3. FBI knocks on PureVPN’s door with a warrant/subpoena 4. PureVPN says “can’t fulfill that right now. We don’t keep logs.” 5. FBI responds “You’ll keep logs starting today.” 6. PureVPN complies, eventually providing the logs FBI needs of future accesses of the suspect This is exactly why people should use Tor before connecting to a VPN and not the other way around. Tor hides you before you connect to an entity that can be coerced to hand over identifying information to law enforcement. But, hey, I could be completely wrong. 1. 3 This is a little tangential but I have to ask… What do you gain by going home → Tor → VPN → internet instead of going home → Tor → internet? In the latter you have one place (home) which all your connections pass through where a wiretapper could correlate them and glean information about what you are doing from the timing information about how many packets you send when. In the former, you have two (home, VPN). This seems like a net-loss of privacy? 1. 3 There’s only two reasons I’d use a VPN for while behind Tor: to gain UDP support, which Tor lacks; or to ensure that my traffic appears to originate from a certain geographic area. 1. 1 The VPN (before TOR) can hide TOR traffic. If I remember correctly, in one case of a false bomb threat a suspect was pinned because they were the only ones on the whole school using TOR. That is, the metadata of using TOR can turn you into a suspect, as it’s not a popular service and TOR usage is scarce. I’m curious about the other way around. How can you connect to a VPN after connecting to TOR? Routing all your traffic throuth TOR using a SOCKS proxy? So if I’m not mistaken, a full setup (with drawbacks of course) could be: home -> vpn (hides tor usage) -> tor -> vpn (allows UDP and hides exit node IP) 2. 2 Some sites don’t allow traffic from Tor exit nodes - routing through the VPN works around that. It also avoids the constant Cloudflare CAPTCHAs. And as @lattera said, UDP support. Some Freenet users use an anonymous VPN, via tor, to hide their IP and Freenet is UDP only. 3. 2 A VPN with more foresight could instead use a warrant canary to let its users know whether the FBI may be keeping logs. 1. 6 We looked in to this for our privacy focused VPN service for the higher education and research sector in the Netherlands. Unfortunately, the legal status of warrant canaries is unclear at best. When a intelligence agency (most have quite far-reaching powers) with jurisdiction and a legal ground compells you to cooperate, not updating the canary probably is a violation of the subpoena and/or gag order because there is no real legal difference between saying “We got a gag order!” and not saying something because you had a gag order. Of course you can calculate the risk and potential consequences when deciding whether a warrant canary would be a good idea or not. Maybe the use of a warrant canary is worth much more to you/your organization than the potential risks of not complying with gag orders. 1. 1 It’s seemingly becoming more and more popular to hide malicious payloads in SGX enclaves. 1. 3 This fix was therefore not backported to long-term distributions such as CentOS: Your daily reminder that long term support with backports never manges to backport all the fixes. 1. 1 but it was not recognized as a security threat. Your daily reminder that Linus would prefer to hide security-related bugs with innocuous commit messages. 1. 2 Yeah, also true, some orgs struggle more than others, but I think it’s true in general, even for the best of us. Mitigations get better, hardening gets harder, part one of a two part vuln gets fixed, etc. 1. [Comment removed by author] 1. 8 It sounds like he doesn’t trust SSL. You don’t need to trust the exit node (doing so is, in fact, highly inadvisable.) 1. 8 Exactly that. I don’t trust the broken SSL/TLS PKI. I don’t trust that my financial institution properly set up SSL/TLS for HSTS and perfect forward secrecy. 1. 2 Doesn’t that mean you should either be switching the bank or not use online banking at all? After all it was described as sensitive. In the end you have to still trust your route to the bank. TLS was not created for Tor, but for whoever is in between your and the target system. Of course one might argue that it is easier to set up an exit node than an IXP, however you still rely on the same means to protect yourself. An attacker might still be sitting in the middle. I also suspect that a sophisticated enough attack to trick one who considers banking to be sensitive and is connection based isn’t that much more likely on Tor. Of course that’s just a guess, but from all that has been observed the majority of attacks have been done on unencrypted HTTP and didn’t even work when someone was using an up to date Tor Browser. What might also make sense is adding your bank (and others) to OONI, which will mean that people/exit nodes targeting these sites might be discovered. At least to my understanding this data is also used for this. 1. 1 The PKI is one of the most tested tech, it’s well polished. The standards cover everything, from the encryption that is pluggable, to the revocation lists, to the decentralization that is possible by having different CI, to the delegation of roles and trusts. Your concerns aren’t with the PKI, they’re with the choice of encryption algorithms (if they add a nounce or any MAC for PFS) and the browser policy (HSTS). Fraudulent nodes are not as frequent and If your browser checks the OCSP or CRL then you shouldn’t have any issues. 2. 6 You don’t have to trust the exit nodes if you’re using Tor to browse Falun Gong literature in China. You do have to trust them if you’re using them to transmit sensitive personal information over cleartext. 1. 2 I thought everyone agreed Tor was for anonymity l, not security/privacy 1. 1 Everyone? Most people have, at best, a loose grasp on the difference between the three. 2. 1 I don’t think it matters, I haven’t tried, but I’d be surprised if my bank even allows logins from overseas without authorising it first, which is what this is going to look like to them. “Oh, you’re on holiday in America, you didn’t tell us that, oh, you’re now in Russia, that was quick”. Plus banks may be able to detect For browsing anyway which would be a red flag? 1. 5 Does OpenBSD have any plans to upstream RETGUARD to llvm? 1. 14 Definitely. The llvm people I have spoken with have pointed out it might be better to implement in the preamble / epilogue lowering functions instead of as a pass, so once we prove it works in the ecosystem and have worked out any kinks, then I will do it that way and submit upstream. 1. 2 Very cool! Thank you for the detailed answer. 2. 3 Sure. Why not? 1. 3 This creates a situation where it’s possible to build a dictionary of addresses for a given firmware, then repeatedly launch the exploit until we have brute forced the correct set of addresses This shows the crucial importance of ASLR. A deterministic address space allows remote attackers to copy&paste exploits with 100% accuracy and reliability. Given the vast amount of hardware that never sees security updates, the exploit code will live on and be successful for years to come. 1. 24 Bring back IRC I say No need to bring it back, it’s always been there. The problem is convincing everyone else to use it. 1. 33 IRC has a fair share of problems which are often circumvented by layering additional services like bouncers on top of it. I like it for its ubiquity, but let’s not pretend it doesn’t show age everywhere. 1. 19 I think matrix could very well be the successor to IRC. Open, federated, secure, multi-device sync and good support for bridges to other protocols. 1. 13 I can’t bring myself to like a communications protocol that’s based on HTTP+JSON, with the reference client written as an Electron app. It just all feels so… inefficient :( 1. 4 The very core of matrix is just the graph behind it all. JSON is just one representation of the information and HTTP is just one transport. Those are the only reference implementations right now, but others are possible, if I’ve understood correctly. But someone more knowledgeable should probably weigh in. 1. 2 Those are the only reference implementations right now The problem with reference implementations is that, by inertia, they end up being the only implementation. 1. 1 Would you rather there wasn’t an implementation? But, in this case, there are several other implementations. There’s the next generation reference home server dendrite (in golang instead of python like synapse) and ruma (in rust). And there are lots of clients. I think only riot supports e2e crypto, but I hope others will start supporting it as it stabilises. 2. 4 To be fair, Riot can run perfectly happy standalone. In fact, I have it running right now on my OpenBSD box. Also, there are many other clients! 1. 5 HTTP+JSON isn’t all that inefficient, just a bit of extra headers, whatever. Matrix is actually fundamentally inefficient in a different way — it’s not ephemeral message passing like IRC or XMPP, it’s a replicated database — and it’s worth it. 2. 6 I stopped using IRC and my bouncer 2 weeks ago for Matrix/Riot on my own server with my own IRC bridges and couldn’t be more pleased. Works incredibly well. edit: was an irssi+irssi-proxy user for over 15 years. Tried every other bouncer. Hated them all. Had a perl script to send my phone a pushover notification for mentions. It worked, but it sucked trying to open up IRC app and find the conversation with no scrollback and respond. Now I have: consistent chat client on every device, always have scrollback, all my logs are stored in Postgres, logs are searchable in every client and the search is handled server-side, and I can do E2E encryption with my friends on Matrix. I will never experience Slack bloat because the federation means I only need one server connection and account. 1. 4 The Riot web app can also serve as a nice IRC client (+bouncer, email notification, etc) if you only need the networks they bridge to. 1. 3 I haven’t been impressed with the quality of tooling or clients yet. Their Debian package documentation is incorrect and commands tell you to… run the same command you just ran. I haven’t seen a client I’ve been terribly impressed by either; Riot is your typical Electron fare. 1. 3 Riot is your typical Electron fare The electron wrapper is completely optional, why do so many people say such things, that’s unfair :( I just use it as a pinned tab in Firefox. 1. 3 Even without the performance concerns of Electron or running in the browser, there’s still the fact these overgrown web apps feel alien in UX on every platform. 1. 2 I’ve found it to be very unperformant and laggy. 2. 1 Didn’t know about this. Thanks for the tip. 3. 10 The IRCv3 working group is attempting to standardise a lot of interesting extensions to the old IRC protocol in a backwards-compatible manner. Amongst other things, they seem to be working on history, standardised registration/authentication, and metadata such as user avatars. 1. [Comment removed by author] 1. 1 It’s really too bad IRC v3 is moving along slowly It is, isn’t it? I am watching their repo on GitHub and get excited every time I get a notification, hoping that it’s about something major like a good history extension. If I had more time I would love to contribute. Wish they had a Patreon account, or something similar. 2. 2 One aspect of Slack I’d be interested to hear any progress on is the fact that it combines chat and fileshare for groups. 3. 1 Is Twitch still running this way? 4. 5 Maybe if it was written in JavaScript, used a million npm packages, invented some new Json/Jose derived protocol,.. then you might have a hope. In all seriousness, I ask myself that question all along. At work we use lync and skype for business and those still feel like a step backwards compared to old Skype, man, icq, and irc. In fact we had logging turned on for a while but the fat xml logs are up our entire email box so it was turned off company wide. 1. 5 Additionally, Slack supports IRC. I just use tmux + issi to connect to Slack and other IRC networks. 1. 6 Slack’s gateway is highly lossy though. 1. 2 What do you mean? I haven’t had a single issue. 1. 12 You lose formatting, inline replies (so you will see out of context messages), that kind of thing. 1. 1 Ah, gotcha. Thanks for the clarification. 2. 4 I’m confident that if a company made an open-source IRC client with the bells and whistles of Slack’s UI, and sold a managed IRC server that was not marketed as IRC, they could eat Slack’s lunch. Instant messaging is a commodity and it makes no sense for proprietary software to dominate the field. 1. 14 IRCcloud comes pretty close to that. 1. 3 IRCcloud has a couple of interesting issues when using it in a business setup. For example, for simplicities sake, they load twitters, facebooks and stripes JS libraries into their webapp, giving third parties access to that data. We talked to them about this and they said they were looking into it, but never ended up doing something. It’s nice otherwise, but I prefer to only use it as a bouncer. Finally, it costs ~5$, so it’s not a feasible chat for many people outside of companies.

2. 6

It’s been done (minus the open source). Used to be called Convore, then changed names to Grove: https://grove.io/

In fact, they conceded defeat to Slack: https://grove.io/blog/closing-shop

1. 3

Grove is better than mIRC, but it’s no Slack. Slack is winning because of UX and polish, not for any technical reason. A competitor would need a native client, with Windows or OS X integration instead of Electron, if you ask me.

1. 5

Those are really hard to iterate on without a lot of people. You’d have a hard time keeping up with Slack’s fire and motion around you.

Possible though. Particularly if you used their IRC gateway to counter their network effect advantage (until they close it).

1. 2

You just want a native slack client?

1. 2

Yes, with an interoperable service provider as well.

2. 6

I think Jabber would make more sense as a modern communication platform than IRC. There’s not much that IRC provides that Jabber conference rooms don’t, but Jabber provides a lot more extensibility than IRC (especially without add-on services like Chanserv, Nickserv, etc.). In which case there are already commercial packages like Cisco Jabber and Openfire that are quite popular.

1. 1

I liked PSYC back when I was comparing them directly since Jabber seemed too complicated:

Whatever we use needs to be really simple and efficient at the core. Then, layers or plug-ins for more complex stuff from there. Preferably, super-easy for library users to add or remove. What’s closest any of you know to that which has a decent chance of being converted into a Slack competitor? Other than IRC.

1. 2

There aren’t many that are federated like IRC. I can only think of Jabber/XMPP and Matrix. But if you look at slack, which doesn’t seem to be federated, you have lots of options, like mattermost, rocketchat, hipchat, …

2. 5

You can’t offer Slack’s UI on top of the standard IRC protocol (it lacks links, images, replies, authentication, history…). Proposals to extend the IRC protocol have not been welcomed by the IRC userbase or by established networks. You could tunnel a custom protocol over IRC with magic strings etc. but this would be inherently clunky and the user experience from any other client would be very similar to using Slack’s IRC gateway. You could publish your custom protocol but what would you gain from that? What’s the value proposition where this idea improves over what Slack offers?

1. 2

Extend IRC all you want as long as the extensions are public. You develop the client and sell the server; established networks don’t matter.

1. 3

Why would this “eat Slack’s lunch”? Theoretically an open protocol would make it easier for others to integrate with you, but Slack attracted plenty of integrations (which now act as a competitive advantage precisely because their protocol isn’t open). Other than that, what’s the advantage of making the protocol public?

1. 1

Well, you’re saying “other than the advantage, what is the advantage?” Another advantage is that it could be cheaper.

1. 1

Well I explained that that particular issue doesn’t seem to have been a disadvantage for slack, quite the opposite.

Building a protocol as an extension of IRC is inherently going to be more expensive than building it without regard to compatibility with IRC, not cheaper.

1. 1

I don’t believe that, but I haven’t quantified it, so we’ll need to agree to disagree. Slack extensions are not interoperable. IRC bots have been written for decades.

1. 1

Slack extensions are not interoperable. IRC bots have been written for decades.

All true. And yet for so many services one might use when developing (e.g. CI), it’s so much easier to find a good Slack integration than a good IRC integration.

2. 2

Proposals to extend the IRC protocol have not been welcomed by the IRC userbase or by established networks

Not sure whether you’re talking about some specific extensions, but from what I can see there are multiple IRCv3 extensions that are implemented by common servers.

1. 17

Awesome work. This’ll open the door to next generation exploit mitigations like CFI and SafeStack. I wonder if anybody in the OpenBSD camp would like to help me in my efforts to port SafeStack to arm64.

1. 1

This seems like a super elaborate but largely unnoticeable prank. “Hey, Jimmy, notice anything different about your cat?” “No.” “Well, you’re in for a surprise! I created a device that creates a portal to another dimension, and then I took your cat and replaced every atom in her body with a different atom that I stole from that dimension.” “Oh… okay?”

What does this actually do? I’m assuming perhaps it thwarts hackers from gaining access to the kernel by exploiting vulnerabilities that expose memory locations (such as Heartbleed), similar to how GameBoys and other game systems are hacked through memory for emulation purposes. Is this accurate?

1. 1

Yeah, I feel the same way. It’s a neat trick, I assume it helps security in some way, but I have no idea how or why I should care.

The only thing I can think of is that it partially defeats vulnerabilities that depend on overwriting kernel code in specific locations, but it seems like it’s solving a symptom, and not the real problem.

1. [Comment removed by author]

1. 1

Full disclosure: I’m going to be annoying and nitpick one word: impossible. ;)

Nothing is impossible when it comes to manipulating weird machines.

The purpose of exploit mitigations is to drive up the economic cost of the attacker. The more costly it is, the fewer potential attackers there will be.