Secure Memory Vulnerabilites

I have long held the opinion that the state of the art of software security is to inflict the maximum psychological damage on the enemy.

Today I checked, the practice is still true today. busy laughing

Here, enjoy :))))))))))
https://git.envs.net/iacore/clean_safe_fun

The Basic Idea

Let’s say you found a vulnerability in your internet-facing application. You patch it- no, wait, no. You sandbox the vulnerability so that it does not affect rest of the system, but still behaves as a vulnerability.

If you don’t know how many vulnerabilites your code has, no problem. Keep adding these secure vulnerabilities until you feel like the intruder is most likely (statistically speaking) going to end up in one of those tar pits. You can easily add intrusion alarms, too, e.g. by dtrace-ing the execve syscall in a program where it isn’t going to happen normally.

Will this idea work? idk. People tend to use social engineering these days. It’s much easier than to stare at the screen for 3 days.

“User” Testimony

so i host the service and send the ip+port to someone to hack.

verdict: not convincing enough. gave up after 3 hours. note to self: next time, use something more motivational like a webshell.

here’s what they said afterwards after i sent them the binary to examine:

looks kind of normal no? what’s the problem?

what’s cap_enter?

Musings

This post was originally supposed to be running a kernel in userspace for hackers. However.

lkl: doesn’t build.

gramine: doesn’t build.

occlum: doesn’t build.

The state of LibOS: doesn’t build.

Should you use Linux for secure applications? Probably not. It is a suitable place for wandering minds to stuck inside, though.