kdbg

https://dayzerosec.com/posts/analyzing-androids-cve-2019-221...

https://web.archive.org/web/20191029172726/https://rietta.co...

- Kaspersky Safe Kids - Does the actual locking/restrictions

- Custom Python Script - Communicates with Fitbit/leetcode/projecteuler/wechall and can update a the restrictions on the Kaspersky website.

Basic setup is that I wrote a script (against Kaspersky ToS) that can login and change the lock/unlock schedule and enable/disable website/application restrictions.

So it unlocks after I tell it to check Fitbits API, and disables restrictions after I tell it to check one of the challenge websites. Locking happens on at a configured time each night.

That is to say, every night my computers and phone will lock me out[0] at a set time. Then in the morning I have to log 30 minutes of exercise (tracked by my heartrate on fitbit) to unlock internet access.

I also have certain time-wasting sites like Reddit and Netflix locked out until I complete a sufficiently difficult problem on leetcode, projecteuler, or wechall

---

I was just finding it hard to keep myself going to bed at a decent hour when I have no constraints like a 9-5 job and to keep an exercise routine going. So this automation has helped me.

[0] My computers are basically totally locked, my phone keeps the phone, messaging, camera, and skype accessible

Edit: To the author the fix is pretty small:

In socket.on('toplist', (data) => {...})

Replace the line:

    $('#toplist tr:last').after('<tr>' +'<td>' + topList[i].name + '</td>' + '<td>' + topList[i].points + '</td>'+ '</tr>');

    $('#toplist tr:last').after($("<tr></tr>").append($("<td></td>").text(topList[i].name),$("<td></td>").text(topList[i].points)))

https://www.openwall.com/lists/oss-security/2019/10/14/1

This writeup does little to explain the issue beyond showing a config line that is vulnerable (but doesn't really explain which part makes it vulnerable). It also incorrectly states the issue is sudo failing to parse the value correctly.

> the function fails to parse all values correctly and when giving the parameter user id “-1” or its unsigned number “4294967295”, the command will run as root, bypassing the security policy entry we set in the example above.

Which is incorrect, sudo parses the value just fine, the issue comes from the `setresuid` and `setreuid` calls. Both treat -1 as a special case that means the corresponding value should not be modified.[0][1]

I mean, sure this article gets the key point that -u#-1 gets you root, but if you're explaining a vulnerability I'd expect the technical details to be correct.

[0] http://man7.org/linux/man-pages/man2/setresuid.2.html

[1] http://man7.org/linux/man-pages/man2/setreuid.2.html

Terms of service violation or something maybe.

If you click Validate it'll shake and turn red, though you can skip ahead all you want, you want it to turn green and add a checkmark next to the title.

Gist of it is you still cut significant calories only eating like 500-800 a day in mostly low fat protien rich foods. Targeting only enough protien to avoid muscle wasting.

While I'm no doctor or nutritionist, my understanding is that it's for that case, you want some of the benefits of fasting like going into ketosis while maintaining lean mass.

Unfortunately I'm on my phone only this week so I can't try and find any studies about it, but I came across it first in connection with type 2 Diabetes. So you might have some luck googling those topics for more info.

Yes...but probably not the way you're thinking.

Most issues are discovered these days through fuzzing first. So there is always a chance your fuzzer will find an issue worth $1M, its much less likely that you'll realize its worth or be able to demonstrate and begin to weaponize the exploit to prove its worth.

Lets rephrase the question a little bit though:

Instead of "Do I would have any chance at all to find something worth the $1M?" lets ask "Would I have any chance of learning this level of exploit development"

Two days a week, lets just round to 50 weeks a year, give you a bit of a break during the year and say 100 days of effort.

So, in a 100 days would you have any chance of reaching the level of being able to atleast write an iOS exploit, ignoring the discovery aspect? Unfortunately, the answer is still no.

But, you would make some serious progress!

A modern iOS zero-click exploit isn't just one issue, in a worst-case (okay there are worse than this, but this is a poor case) scenario you might need the following issues

- Memory Leak + Entry Point service exploit - Sandbox Escape to low priv user - Privilege escalation to higher priv user - Kernel memory leak + Kernel exploit to finally get root privs

This even for someone with experience, going from fuzz result to exploit can take months. So in a 100 days of spread out effort, you won't be doing that, but you might be able to begin approach that first stage, a memory leak and an exploit in a user-land service.

I do only say might because 100 days is a really short time when you think about how technical your knowledge of this stuff needs to be, but I'd like to think that with some real determination, in 100 days at least foundations of modern software exploits should be approachable.

As for would it make sense for you to even try, the best time to start was 20 years ago, its been getting increasingly more difficult. The longer you wait the higher the barrier to entry gets.

We are not putting out any new episodes right now though, I'm currently off on a long-distance hike.

I don't recall needing to provide any documentation? I'm also not American so I couldn't provide "US Based documentation" whatever that means.

There also wasn't any back and forth interaction with support to get unbanned.

We appealed it and were reinstated pretty quickly (hours), which was a genuinely surprise to me given all I've heard about the Youtube system and the assumption that channels only got unbanned by being able to attract attention.

Shortly after we uploaded our 4th episode we were banned on Youtube. We appealed the ban and were allowed back on pretty quickly (hours) and we are by no means a large channel even now (~50 subs).

My understanding is that use a patch file as long as your patch doesn't include any copyrighted material it is fair to share.

A patch file does not necessarily have any of the original code, just the location info and the new value.

Perhaps you don't want people knowing who you're donating to, and the third party offers that privacy?

That seems like a fair trade-off to me, but it is indeed a trade-off between privacy and usefulness it is one I appreciate though.

This is kinda what the Basic Attention Token is in the Brave browser.

You can either tip directly/manually, or setup a monthly payment that gets split automatically among the places you most read. It doesn't require the creator already be a member, but rather it holds the funds until they register, or until 90days have passed.

They've also built in some significant privacy features so that no one can determine who/what you're donating to. Though this leads to one of the contentious issues as refunds are not possible, so when the above mentioned 90 days passes without a donation being claimed, the funds go into the "User Growth Pool" which basically means they are given out to new people joining BAT as an incentive to join.

The big controversy though was exactly the issue of not requiring people sign up before they started accepted BAT donations to them. They had a system of showing if a user was 'verified'[0] meaning they were registered to receive the donations, and nothing would be shown if they were not verified.

This led to an issue where Tom Scott commenting that Brave was taking donations on his behalf without his consent. [1]

Imho that was hugely damaging to the potential of BAT and I think really stemmed from people who didn't use BAT and didn't understand the Verified/Unverified aspect of it. They've added a Non-Verified statement and icon now to make it explicit, but the damage has been done.

[0] http://se.ri0.us/2018-12-22-184516548-9adee.png [1] https://news.ycombinator.com/item?id=18734999

The core feature is Domain Tagging. The architecture adds 2 bits to data that define its 'domain' (code, code pointer, data, and data pointer). On its own this does nothing for security but it allows the churn unit to implement the two moving target defenses.

Pointer Displacement is the first moving target defense. It obscures pointer values by adding a random display to them and is domain dependent. So, the churn unit is able to find all code and data pointers and obfuscate them. Basically the same as encrypted pointers except they can be encrypted with a new key at run time.

Domain Encryption is the second moving target defense. It'll encrypt each domain with its own key. Details are sparse on how the encryption works, just the following quote:

> the domain encryption defense randomizes the representation of code, code pointers, and data pointers in memory using a strong cipher. These assets are encrypted in memory under their own distinct domain keys.

Both of these are actions performed by the churn unit which can be turned to run at a desired frequency or when certain rules are violated.

On the topic of rules, there are two types of rules the architecture enforces. ABORT and CHURN. Abort does the obvious and terminates the program, CHURN causes a re-randomization.

Aborts can be caused by:

- Attempting to execute anything not in the Code domain

- Use a Code data (not code pointer) in any instruction

- A jump target that isn't tagged as a Code Pointer

- A Load/Store address that isn't tagged as a Data Pointer

CHURNS can be caused by

- Performing an inter-domain comparison, the tags must match

- Any Code pointer arithmetic

- Any Data pointer arithmetic

- Any overflow occurs

- Invalid shift length (shifting by more bits than there are)

So on-to your question regarding ret2libc and friends. Basically, its an extra layer. A lot of attacks require that you leak some memory address (assuming ASLR is enabled) that is then used in the attack to, for example, craft a ROP or JOP chain. With pointer encryption you also need to leak the encryption key in order to craft a valid pointer.

Then you need to do so without causing violating an abort rule (shouldn't be too hard) and without violating a churn rule. The churn rules are potentially problematic as overflows are a common trick to getting certain values, and pointer arithmetic in general. As both cause churn that could invalidate the data you just leaked.

As for the root question of how can a valid application look up the memory, well its the architecture that decrypts the pointers/data in the architectures instructions (not adding new instructions like some pointer encryption implementations for example). So the program just needs the right pointer at run time, and the churn unit will rewrite them when it runs and changes the keys.

Honestly, it seems like a pretty solid mitigation for the types of attacks its designed to mitigate. An impossible barrier, I doubt it, without being hands on and trying to exploit it I can't speak with absolutes, but it certainly would be a challenge.

Though as many other have said, there are plenty of attacks it does nothing against but the paper is far more modest and accurate about the intent than the .edu post.

From the abstract:

> Morpheus defenses offer strong protection against control-flow attacks

Without access to the paper it's hard to say how granular the randomization is, and what is static. It's apparently transparent to software but there needs to be some source of relative location information that can be accessed.

It also mentions detecting imminent attacks and increasing randomization rates.

I actually learned this the hard way, I was in your shoes, 100% remote job, for a US company, US clients, and went to Europe and thought I might work while traveling. I was detained at the border, interviewed, and very nearly denied entry. I was let after a couple fairly lengthy interviews (I was detained for about 16hours) and proving I had funds to support myself without working. I was given a "visitor record" and a firm exit by date, not sure what all the record entails but I get questioned every time I enter now.

Anyway, point being, legally speaking what generally matters is where you are located when performing the work, and that's really the only way that makes sense to judge where the work takes place.

With all that said, in reality being caught is extremely unlikely and plenty of people get away with it and I don't think there are many countries actively trying to crack down on that sort of short term work while being a tourist. If you want to be above the board though, unless your work counts as what a business visitor can do, you would need a visa to perform any work. There is generally no distinction between traveling for the purpose of working, and working while traveling for other reasons.

I'm not a lawyer though but I've spent a fair bit of time actually looking at the restrictions on the tourism and business visitor visas to stay legal while traveling long-term and working remotely.

I don't remember how I first heard about Linux or Knoppix but I do remember those first magical moments using it. While I've had many influences Knoppix definitely was an early influence on my tech interests because it was so easy to start.

The first one (magician) went as you stated, I ended up hating it, or atleast hating it as a job. It paid pretty well, but performing because I had to instead of wanted to made a big difference.

On the other hand though, I also took my hobby of hacking stuff into the my current career doing application security consulting and vuln research. Also pays quite well and I enjoy my job quite a bit, possibly even more than doing it as a hobby.

So with a sample size of me, that's 50/50 odds on finding something you love working out as a job you love. Not great, but imo not reason to atleast take a shot if your passion also happens to pay well, and is feasible.

Well, it should. It kept having issues with the only APK I had on hand, but when I just pulled some DEX files out and loaded them it handled them just fine (including decompilation)

It has a grayed out message and a link to learn more about what happens to unclaimed funds: http://se.ri0.us/2018-12-23-170628027-eb454.png

That said, I did ask the few people I know that have been using BAT. All three of them knew that there was a chance their tip wouldn't be received if it wasn't a verified user. So, from actual users, putting actual money into it, they understood how it worked.

Two of them specifically would only tip to verified accounts. The third said he saw it as an incentive to get the creators to join the platform, though he's also the most vocal and evangelistic about BAT.

It has a pretty obvious mark under the name if they are verified.