bahorn

Stack Clashing is pretty neat, something you should really pay attention to in embedded spaces (its often exploitable in UEFI land as most EDK2 builds lack guard pages).

I got to write some exploits for some recently, very fun bug class to exploit.

Bit confused on how this group got access to the rabbit codebase, as this sounds closer to backend code and not jadx'ing the APK.

Are there any details on that?

I understand the issue, I have checked /dev/pts/ and seen systemd-run create a user readable pts there. I'm not adverse to that one getting chown()'d, but there really isn't any impact from it.

The problem is you can not hijack (meaning command exec right?) a root shell running under your account with this unless there is an approach that hasn't been mentioned yet. You can read character input, stopping the program from receiving input while you are doing so, of a process your user account directly started. I investigated the other ways and he hasn't given a viable one beyond running stuff directly in shell of the target session (TIOCSTI doesn't work if you target a different pty) or using ptrace.

All of these apply to other programs as even though they set root permissions on their pty as you can influence their parent. You need to chown both if you want to stop issues, but that'll probably break stuff. To be clear his whole point is that systemd is less secure compared to sudo etc but is using something that applies to everything to try and show that, involving using pocs that didn't even show the issues he was claiming, which is disingenuous.

This is not a systemd-run specific issue either.

I reproduced this targeting sudo (just `cat` the parent tty), in fact able to capture my password as I type it in, and capture commands as they are being typed in. Surprised it was not mentioned that it breaks the terminal while you run it, no characters get sent to the program.

Edit: Here is a POC https://gist.github.com/bahorn/198987f55611f2011a91a5af09e7c... so you can see that this applies to sudo as well.

I put a bit further thought into this. The claim is that because the pty has user permissions its possible to hijack it, but that really hasn't been true for years which is why the two PoC do things like use reptyr (involves replacing fd's with ptrace [1], needing either a parent relationship or capabilities that aren't default) or running a command like netcat directly from the pty you want to control [2] (essentially ttyjack [3]).

If you look at the implementation of TIOCSTI [4], 99% sure this is what the new PoC is doing, you can see why you can't do this across ttys. This goes back ages, even into some 2.6 kernels it seems before I got bored going back kernel versions.

I went and tested all this on a Ubuntu 22.04 box, not possible unless there is a new trick to hijack ttys. I tried the TIOCLINUX across ttys physically at the machine and that didn't work either.

[1] https://blog.nelhage.com/2014/08/new-reptyr-feature-tty-stea... [2] https://twitter.com/hackerfantastic/status/17860809689581612... [3] https://github.com/jwilk/ttyjack [4] https://elixir.bootlin.com/linux/latest/source/drivers/tty/t...

This is not a real bug and the trick is possible with sudo if you just hijack the parent process of sudo with reptyr instead of sudo directly.

Also seems a bit absurd to try and pretend there is a security boundary between processes started by the same user. You could already do PATH trickery here, a time honoured tradition.

From their FAQ and blog posts, I don't believe they apply much FHE. Seems what they do is use work from a different subfield [1], which seems to be able to achieve the required speeds and still be able to work with more complex queries.

Techniques I'm seeing in the Pappas et al. paper mentioned in the history section of [1] to do more complex queries seems pretty cool, and I imagine the performance has been improved a bit in more recent work.

[1] https://en.wikipedia.org/wiki/Searchable_symmetric_encryptio...

It actually does run on KVM! I spent yesterday trying to get it to work and found the trick was setting the chipset to i440FX, and putting every drive on the IDE bus.

Probably not a reasonable choice for any real usage though.

Far from the most qualified to answer this but it's probably a mixture of market demand, the targets, mindshare and QA.

Higher value targets tend to use iOS more often so their adversaries have more interest in attacking it, and the targets are people who are more likely to come forward if they suspect being attacked. And given we've heard more of iOS attacks, people likely to be targeted are more on the look out for them, as a bit of a self fulfilling prophecy.

Android is considered a bit of a harder target for these types of exploits (playstore malware doesn't count here), though at this level it's not the most meaningful distinction. Fragmentation does make it harder to use these sorts of things in the android world, as it's a bit harder to do QA against all the possible target devices and probably requires knowing exact model numbers to confirm support before being able to launch an attack. The exploits do definitely exist however, at least for flagship phones.

Another thing to consider is that maybe people have better payloads on android, as you can't quite get away with running "Payload2" on the device from a temp directory when process viewers are available. I'm somewhat unsure that'd actually be a meaningful reason for lack of discovery though, especially when the discovery is mostly done by journalists forwarding suspicious links to citizenlab.

I stumbled upon a talk from GRCon18 a few weeks ago where they did this [1], though on a much more restricted testcase.

Find the idea interesting, but I'm curious how resistant it is to attackers who know you are using it / how you'd design things to make backdooring in a way that isn't noticeable hard.

[1] https://www.youtube.com/watch?v=gDGzc_4wcjM

I've ran some student hackathons in the UK (worth noting we have a very different culture than the US scene) and we actually tried to discourage the whole working 24 hours straight thing.

Events are more just workshops / hanging out, with projects being more of a secondary thing.

Worth noting that it's quite common for people to not be publicly listed as part of Github organizations. The archive.org snapshot of the organization page from February [1] shows the same member count, so suspect that's the reason.

[1] https://web.archive.org/web/20210224203331/https://github.co...

While the authors of this definitely didn't handle this well, I'd argue it's a pretty severe weakness and the tool shouldn't have been released in this state. Active probing has been observed in the wild [1] and pretty much all tooling in the space handles it in their threat model [2], so its naive to not consider it.

I get why the signal team wanted something to use HTTPS, even networks with completely insane firewalls accept it and they get to reuse existing domain fronting code, but existing tools continues to viable in Iran and would have made much more sense in the circumstances.

[1] https://blog.torproject.org/learning-more-about-gfws-active-...

[2] https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec....

The google form lists the prices in an image:

* $119 for 4GB of RAM

* $149 for 8GB of RAM

But the early version apparently is only the 8GB variant.

Been using the project for a year now and submitted a few patches. It's a fun project to hack on, so would recommend getting involved if this sort of thing interests you.

Regarding the value of RGB, honestly one of the cooler uses which the projects been enabling is showing things like system status on your devices. And beyond that, getting a cool pattern or mode implemented is just a fun weekend project.

I arranged everything on day I needed to move on (except in Dushanbe where I arranged the transport to Khrough via the hostel, who I just told the night before). Worked even on the Monday after Tajikistan's Independence day (when I needed to head to Murghab), so you shouldn't have many problems.

Just go to whatever the local meeting point early enough and you'll get a ride. Tend to leave by 10-11am IIRC. Try to get the front seat as they'll overpack the cars to an extreme.

I only did the main route and didn't head down to the Wakhan valley, where I gather you need to find people to travel with to cover the costs.

Random tips / things to be aware of:

* Breakdowns seems to be pretty normal. They do know how to fix their cars though so you shouldn't panic. Had this happen twice on the Khrough -> Mughrab section.

* There are some lovely villages on the road to Roshtqala. I did a homestay in Tusen and the scenery around there is amazing. The place marked as "Shokhdara Bus Station" in Khrough on OSM is where you go to get transport here.

* Public transport between closer villages and around Khrough is pretty reliable but it doesn't run on Sundays. Bit of an adventure to get though.

* ATMs exist in Khrough and do accept Visa, but none as far as I'm aware in Mughrab (And the banks weren't open in Mughrab while I was there due to the time of year)

* No accommodation in the Pamirs has persistent internet connectivity, even if they advertise it. It's all 3G/4G connections they leave on only for a few hours a day (if that). This becomes an issue when you need to figure out where to stay in the next place on your route.

* The GBAO permit is cheaper if you do it in Dushanbe and don't get it with your evisa.

* Caravanistan and its forum has so much useful information. Planned my whole trip around the site.

I did the journey in early September, starting in Dushanbe, as part of my backpacking trip throughout Central Asia. Highlight of my trip.

Surprisingly easy to travel as a lone backpacker nowadays as you can arrange transport on the day on all the major stops of the main route. (Dushanbe -> Khrough -> Murghab -> Osh). Cost of the main route was something like $70 in shared taxi costs.