drspod

joined 3 years ago
[–] drspod@lemmy.ml 22 points 23 hours ago

Silk Nukem SongNever

[–] drspod@lemmy.ml 19 points 1 day ago (2 children)
[–] drspod@lemmy.ml 3 points 1 day ago

Most recent episode is 17th Jan. Did they stop?

[–] drspod@lemmy.ml 22 points 1 day ago

Perhaps memory loss is a symptom of long covid.

[–] drspod@lemmy.ml 13 points 1 day ago (1 children)

You'd want to forget too, if you shit your pants 6 times a day.

[–] drspod@lemmy.ml 1 points 2 days ago

Why are you posting this low effort slop?

[–] drspod@lemmy.ml 3 points 2 days ago

Deckard has been viewed as a long-awaited successor to the Valve Index, which debuted almost six months ago.

Wow was it that recently? It feels like 6 years!

[–] drspod@lemmy.ml 5 points 2 days ago

I want my altavista back

[–] drspod@lemmy.ml 2 points 2 days ago (2 children)

Substack is Geocities for the Tumblr generation.

[–] drspod@lemmy.ml 7 points 3 days ago

An SEO ghoul's wet dream.

[–] drspod@lemmy.ml 27 points 3 days ago

The original report: https://www.zimperium.com/blog/catch-me-if-you-can-rooting-tools-vs-the-mobile-security-industry/

This isn't so much security research as it is marketing for the company's mobile endpoint security tool.

Their stats on the surface are interesting. According to the data collected by Zimperium:

According to our data, the exposure factor of rooted devices versus stock devices varies from 3x to ~3000x, which suggests that rooted devices are potentially much more vulnerable to threats than stock devices.

But then the paper doesn't even speculate as to why that might be. The rest of the report is basically a sales pitch for their security software. Rooting is bad and you need to keep these devices off your corporate networks (by buying our software) is the only message they're sending.

Off the top of my head, here are some hypotheses for the correlation, each of which has different implications for how to best mitigate the risks:

  1. rooted devices are more likely to produce false-positive security alerts in the endpoint detection software
  2. rooting tools themselves are used as an initial loader in infection chains
  3. users of rooted devices are more technical and therefore more likely to install more apps overall, increasing attack surface area
  4. users of rooted devices are more technical and therefore more likely to engage in risky software installation (sideloading untrusted software)
  5. rooted devices contain more vulnerabilities
  6. stock OS security is good at stopping malware from misbehaving, rooting removes those mitigations

The implication of the paper seems to be that (5) or (6) is the case: "rooted devices are potentially much more vulnerable to threats than stock devices." If the cause is (3) or (4) on the other hand, then there's not much that can be done outside of user education, since these users are inherently more likely to increase the attack surface of their devices whether the device is rooted or not.

(1) or (2) however would imply that the whole research is bogus, as in the case of (1) the data would be completely unreliable and in the case of (2) the causation is actually the reverse of what the paper implies, which is to say that malware causes rooting of the device, not the other way around.

Interestingly then, the paper includes this illustration:

Figure 4 illustrates this idea, showing a case of a rooted device that ended with a full compromise after sideloading malicious applications.

An image showing an infection report from the security tool.

The infection with malware occurs 10 seconds after the installation of Magisk, the tool used to get root access to the device. It should be obvious to anyone that this was not a coincidental infection caused by the user rooting their device, but actually the malware was using the rooting tool as the first step in compromising the device. So in this case, malware caused rooting of the device, not the reverse.

The linked Hackread article essentially just regurgitates the points from the Zimperium report without any critical analysis of why or how rooted devices pose a threat. For users of rooted devices it would be helpful to know whether they are actually at more risk, and why, so that they can mitigate the risks. But this article is not about security research, it's just a sales pitch.

[–] drspod@lemmy.ml 14 points 4 days ago (3 children)

Don't ask to ask, just ask.

 

Actually I'm not sure what the difference is between a raffle and a sweepstakes. Is it like a tombola?

I'm not trying to start an argument it's just, ngl i could really use some of those empty cans rn

 

AMAB

 
53
submitted 2 months ago* (last edited 2 months ago) by drspod@lemmy.ml to c/technology@lemmy.world
 

This is a moving story about a cafe in Japan that allows house-bound people to join in with society and find a purpose, using remotely operated robotic avatars.

 

If you want to go straight to the original write-up, it's here: https://eieio.games/blog/bad-apple-with-regex-in-vim/

 

Great craftsmanship from this maker and the end result is impressive.

If you want to skip the construction process and just see the end result, skip ahead to 41:20.

 

Edit: this appears to be fixed now: https://lemmy.ml/post/22203615/14801411

All images in posts on lemmy.ml are currently being resized to 256px on the longest dimension (width/height), even if they are image posts, not intended to be just article thumbnails.

Is this an intentional change? It makes text in images illegible and means that I have to view the original post to see the original image on every image post.

If this is a deliberate space-saving measure, could it be tuned for a little better usability? For example, increasing the maximum size of image when the post is an image post (as opposed to a web link that generates a thumbnail) and setting a size threshold to trigger resize (ie. most small images could be left alone).

Some examples from my feed:

 

Threat actors are utilizing an attack called "Revival Hijack," where they register new PyPi projects using the names of previously deleted packages to conduct supply chain attacks.

The technique "could be used to hijack 22K existing PyPI packages and subsequently lead to hundreds of thousands of malicious package downloads," the researchers say.

If you ever install python software or libraries using pip install then you need to be aware of this. Since PyPI is allowing re-use of project names when a project is deleted, any python project that isn't being actively maintained could potentially have fallen victim to this issue, if it happened to depend on a package that was later deleted by its author.

This means installing legacy python code is no longer safe. You will need to check every single dependency manually to verify that it is safe.

Hopefully, actively maintained projects will notice if this happens to them, but it still isn't guaranteed. This makes me feel very uneasy installing software from PyPI, and it's not the first time this repository has been used for distributing malicious packages.

It feels completely insane to me that a software repository would allow re-use of names of deleted projects - there is so much that can go wrong with this, and very little reason to justify allowing it.

 
 

A reported Free Download Manager supply chain attack redirected Linux users to a malicious Debian package repository that installed information-stealing malware.

The malware used in this campaign establishes a reverse shell to a C2 server and installs a Bash stealer that collects user data and account credentials.

Kaspersky discovered the potential supply chain compromise case while investigating suspicious domains, finding that the campaign has been underway for over three years.

view more: next β€Ί