I have a webapp that generates PDF files from several user-supplied fields and can use CSRF to change those fields. Is there a way I can try to put malware (e.g. rev shell) in the output PDF by controlling the fields?
@JohnZhau I don't know enough about PDFs, but I'm dubious about a reverse shell. Many PDF readers can run JavaScript thought, but theoretically you will be sandboxed. Presuming you're looking for something for a bug bounty submissions, I might try looking into running cryptomining in a PDF via injected JavaScript, if that's possible
I was just reading about this for the first time and thought it was hilarious, so I might as well share:
The Emu War, also known as the Great Emu War, was a nuisance wildlife management military operation undertaken in Australia over the later part of 1932 to address public concern over the number of emus said to be running amok in the Campion district of Western Australia. The unsuccessful attempts to curb the population of emus, a large flightless bird indigenous to Australia, employed soldiers armed with Lewis guns—leading the media to adopt the name "Emu War" when referring to the incident. While a number of the birds were killed, the emu population persisted and continued to cause crop destruction...
Such a budget will, inevitably, fall under an executive department, headed by either a Cabinet Secretary, or the President himself. The budget for that department is scrutinised by Congressional Committees.
Both the relevant Cabinet Secretary, and the senior members of the relevant Congressional...
Is everyone in the congress a trained accountant?
And what's the point of oversight, if everything has to be kept secret?
Basically the oversight is: Committee: "Where is the money going?" "Here, here and here, but it's all classified so you can't do anything about it"
here, "government black budget" isn't even in the books...
it's more like this: you do some service to the government and charge $100k, but someone comes and asks you to charge $150k, wire that extra $50k to someone else, or your services won't be needed anymore, forever...
and that "someone else" sometimes isn't even aware of anything, because his documents were misused to open an account somewhere that does not care much about your ID at all
funny story: a woman was fired from his work, and went to work somewhere else... the new job asked her to open an account at a specific bank (it's a nuisance but common occurrence here) so she would be paid. when she got to the bank she was informed that she already had an account there. she would be paid around $1k/month on her job and the account already had around $150k.
she said she wasn't aware of that, asked the account to be locked, and went to the cops. they found out her former boss was the secretary of a senator, and she was using her account to receive those kickbacks...
here there's a national registry for dead people, and the banks are required to update their databases weekly if I am not mistaken
I know that insurance companies refresh their databases weekly, because some miscreants usually pay insurance for dead people and file for damages later
why do I always feel like writing my own password manager?
I took a look at the source code of "pass", which is a bash script that uses common linux tools like gpg. I was curious how it managed to edit passwords without writing them on disk, and it turns out it does write them on disk, in a temporary file which can be edited with vi, but then uses shred to delete it
my idea would be to write something like "pass", but much much simpler (and customized for my needs), where everything is kept in bash variables and never written on disk. Then the only problem left would be swapping I guess, which I wanted to disable anyway, but I could add a "swapoff" command at the beginning of the script anyway
> my idea would be to write something like "pass", but much much simpler (and customized for my needs), where everything is kept in bash variables and never written on disk.
there are 453 password managers. - what? 453? let's make a password manager that solves everyone's problems, it's safe, small, portable, and run everywhere, from mainframes to arduinos... ... there are 454 password managers.
You disable swap. You run in bash PASS=hunter2, so bash allocates some memory from the heap. It can't swap it out because swap is disabled. Now you unset the variable, so bash frees the memory used by PASS. You re-enable swap. Unfortunately, "hunter2" is still there in unallocated memory, and gets swapped out.
Anyway, a personal password manager is easy to write. I wrote my own since I have my own use for it, but mine doesn't use encryption, because my disk is already encrypted and I use mandatory access controls to protect the contents of the file at runtime.
But it'll still leak into memory during context switches, although Linux doesn't use "true" swap so the saved execution context won't get swapped out (it counts as kernel memory, which doesn't swap).
But if you really need swap, you can just have encrypted swap easily. :)
But if you don't want something to be in swap, mlock() is what you want.
you can store the data encrypted, only decrypt it on the moment you need it, ask for the decryption password as late as possible, store the decryption key on volatile register variable, so it won't be swapped out
maybe volatile register is overkill and reduces the amount of registers available. mlock() is enough for almost every case
Given that you'd need 2 or 4 registers (or 4 to 8 on a 32-bit system), it'd be better just to lock the memory. Using registers also doesn't guarantee that the compiler won't shadow the value as part of some optimization, even if you do use volatile to disable optimizations with side-effects.
Or the key might be on the stack before it's saved to the register, and unless something overwrites those bytes on the stack, they'll be free to be swapped out.
Sure, but that's going a long way to keep something out of swap when mlock() already works. :P
I've worked on a project where I had to ensure that some data in memory would never touch RAM (not even temporarily), and it's actually surprisingly difficult. I had to "spread out" the data so that a single SMI that would only cause 64 bits to be leaked to memory would not be able to reconstruct the data.
This kind of thing requires careful threat modeling, because sometimes it's as easy as tweaking some C code. Other times it requires modifying the kernel. Other times it requires different hardware.
when I saw someone writing a full 3d FPS with enemies, soundtrack and textures using only 98kb of code, I stopped doubting what could you do in x86 assembly
.kkrieger (from Krieger, German for warrior) is a first-person shooter video game created by German demogroup .theprodukkt (a former subdivision of Farbrausch), which won first place in the 96k game competition at Breakpoint in April 2004. The game remains a beta version as of 2021.
== Development history ==
.theprodukkt have developed .kkrieger since mid-2002, using their tool .werkkzeug (from Werkzeug, German for tool). They used an unreleased version of .werkkzeug called .werkkzeug3. The source code of .werkkzeug3 engine was made available by the group in 2014, either under the BSD license or...
(To be fair, 99.99% of that will be virtual memory that doesn't map to physical pages, but still...)
I miss the days when every cycle and every byte was precious and valued.
Nowadays everyone's like "pft only a million cycle overhead on this inner loop? Why should we bother optimizing that out when we're doing 3 billion cycles on 8 cores?"
So what, does it have something like an odometer that keeps track of how many cycles passed, and you have to faithfully report that to IBM? Or is it automated?
So I take it the system automatically uploads the cycle count on a monthly basis, and will refuse to run if IBM doesn't return some kind of DRM-esque code indicating acknowledgement?
there's a software that I don't remember the name running all the time and it records the maximum amount of cycles you used every hour. So if you used 75% CPU in one hour but 10% 23 hours, the entire day is charged 75%
the problem is that you can only run mainframe code on mainframes... and there are no platform as resilient as a mainframe. so no matter how draconian this scheme is, and how expensive are both hardware and software, banks use mainframes for their core business and they don't think much on changing platform
you can kinda run mainframe code on emulators, but it's against the EULA, and the performance is abysmal..
so while is technically possible to run mainframe code on x96 systems, you will need so many top line x86 servers that will end up being more expensive than buying a mainframe
5 years ago I saw someone running an emulator on a (then) last-gen i7 and achieving 20-30 MIPS (meaningless indicator of processor speed), and back in 2002 I worked on an old mainframe with 700 MHz and it had around 800 MIPS. so the math isn't very promising.
and if you bypass it, you may end up paying a hefty fee that would cover a decade of mainframe usage or having the mainframes shutdown and taken away for breach of license. and that would be more devastating than a ransomware that lost the private key for your data
@forest I doubt so. zOS isn't donwloadable, the code is shipped on sealed disks and carried by career IBM engineers that won't risk their jobs leaking it, and customers are under contract to not leak it
btw, thanks for telling me my site was down... it's up now and now it have usable data
@forest IBM did a lot of good things, and a lot of bad ones too... the PC standard was great, for example. and the idea of creating software not tied to the hardware was great too
External attackers are still protected against by disk encryption. Local attackers (compromised browser, malicious user process, etc.) are protected against by access controls.
what do you do to become root, or have root privileges for administrating stuff? This is actually a question I might ask sooner or later here on SE. I use the usual "sudo", but that means I'm basically already root all the time (sudo is easy to bypass by malware).
I was thinking I would need a separate root account, and switch to it in some "safe" way
It's a sysrq combo (on Linux) which kills everything in that session. That way a malicious non-root user won't be able to hook the "switch VT" keys and display a fake login.
But even if they did, my system won't let anyone get root from a lesser user, only from a login with agetty. So the SAK combo is more to prevent it from setting up a fake root to record me entering sensitive data somewhere else (i.e. the password itself is not too sensitive).
@reed You have to enable it with the kernel.sysrq sysctl (it's a bitmask). After that you just do the combo and the screen flickers once as the running agetty is killed and respawns.
If you totally trust people who are physically at the keyboard (and use a screen locker which disables SysRq), you can just set kernel.sysrq = 1 to enable all SysRq commands.
The common combos are REISUB (SysRq-R, SysRq-E, SysRq-I, SysRq-S, SysRq-U, then SysRq-B).
That's return control from Xorg to terminal (R), send SIGTERM to every process (E), send SIGKILL to all processes (I), sync disk buffers (S), remount all filesystems read-only (U), and emergency reboot (B). That's the common combo which is used to recover from a locked up system.
But there are others like SysRq-F which triggers a manual oom_killer event.
You could run f="/proc/sys/kernel/sysrq"; cat "$f"; sleep 30; cat "$f" and start the screen lock and unlock it after 30 seconds. That should tell you if it disables SysRq for you.