so our DPRK Contagious Interview friends have advanced in the meantime and now have started reking people for which you only need to _unzip_ a file and run a git checkout or commit operation.
so this how the attack works:
1. the attacker distributes the repo as a zip archive (which is pivotal!). this is on purpose because git clone explicitly strips hooks (since cloning goes through git's _own_ protocol which excludes them) from remote sources as a security measure but unzipping is just a _normal_ filesystem ops that git cannot control (yeah fml but also simple fact). the zip restores file permissions exactly as the attacker set them (expect `rwxrwxr-x`), so the two active hooks (`pre-commit` & `post-checkout`) arrive on disk already executable (yeah fml).
2. git _automatically_ runs a hook when two conditions are met at the same time. the file must have the correct bare name with no `.sample` extension _and_ the executable bit must be set (like `rwxrwxr-x`). both of these are already satisfied by the attacker _before_ the zip is distributed. no fucking user action, config change, or approval is needed, git's own hook dispatch system triggers everything lmfaooo. software is great innit?
3. some of the custom `.sample` files in the shipped `.git/hooks` directory are the malicious payloads. they are basically payload components _disguised_ under innocent names. once the victim does anything beyond passively inspecting the repo (e.g. git checkout or git commit), the _active_ hook copies those files into `~/.vscode` (a directory devs usually trust and ignore but well you should not trust it guys) and then starts a detached background process using `nohup` so it does not block or visibly affect the git command. the git operation still completes normally and nothing looks suspicious. fucking evil, but hey here we are!
4. now that background process then bootstraps a node.js runtime if it is not already installed, runs npm install using an attacker controlled package.json, and executes an obfuscated payload (this can ofc differ and change over time). from that point the attacker gains clipboard access, a persistent c2 channel over https://t.co/SZ5Ym88c3r (usually) and the ability to read browser credential dbs
@CoWSwap A very respectful move, especially compared to LayerZero. Still, a 2 month rather than a 2 day claim window would do more to signal that DeFi has finally reached maturity.
Anyway, hats off for demonstrating such strong values. Good luck!
@z0r0zzz@heckerhut@apoorveth That is something to be built. I am going to present the CALM ERC on ETH Prague hoping to build up the community / working group with the focus on such a CALM library. You are cordially welcome to join it.
@0xZulkifilu Nice post. Wrt EVM - EVM does not know anything about these visibility types. Contracts have one access point only, where solidity compiles dispatcher with public and external functions handling.
Private functions are annoying to test-they cannot be called from test scripts.
@danielvf Nice schematics.
Bytesize optimal is PUSH0 NOT PUSH1 SHR AND sequence (6 bytes vs 22; 8 gas more). But you might prefer push20 when using ERC 8167 or diamond proxy and are thus not limited by contract size.
@0xZulkifilu Hope this approach can save some - require the access tests on **every** external/public function as a part of the test suite.
And by every I mean even those inherited.
@0xZulkifilu E) It literally removes the check for the msg.value - this results in B option
And it is the reason one can see it with constructors (fewer bytes/gas)
Nice quiz.
@0xZulkifilu Meaning - try to look under the hood what the nonReentrant modifier does. And how the similar behaviour can be achieved in this case without extra storage impact.