What is "asd" process?

[Yota]

It actually has no reason to scan the hdd, since no execute permissions should be allowed there.

Asus got it wrong with security to begin with and is now patching it up in a stupid way.

It might help to write a script that constantly checks and kills the process, although it seems like rc keeps waking it up.

I think that process was brought into the Merlin firmware with AiMesh, which I thought was part of AiMesh for a long time.

After every reset I do, I enter these below commands to block the stupid logging of the process, it doesn't even output the logs to syslog, instead it just produces garbage files in /jffs:

rm /jffs/asd.log; mkdir /jffs/asd.log; chmod 644 /jffs/asd.log

 

[glens]

You should know that I'd "Linuxed" something relative to the ssh shell, and saw it relatively-promptly deleted, to my utter dismay!

Discovered the "better" way, but really?

Gotta say I'm a fan of many options, but don't think I've got what it would take to support the result.

 

[zitev]

Directly.

Your assumptions (quoted above) are not correct.

these are not assumptions, but facts, but we do not agree on this..

 

[Yota]

As already stated, there is no option to turn this off, otherwise it would be completely useless since any malware would be able to turn it off itself before installing its payload.

It looks like it can be disabled every time the router is started like this:

touch /tmp/killasd && killall asd && mount --bind /tmp/killasd /usr/bin/asd

If I can find a way to disable it in ten minutes, there's no point in having this security daemon exist.
(I am not a developer)

EDIT:

Well, disabling asd had a noticeable side effect, /sbin/init was over 50% CPU usage, I'm guessing this is caused by constantly trying to run asd.

But malware authors don't care about the CPU usage of the victim's router, they now have an easy way to disable it if they want to.

 

[zitev]

It looks like it can be disabled every time the router is started like this:

touch /tmp/killasd && killall asd && mount --bind /tmp/killasd /usr/bin/asd

If I can find a way to disable it in ten minutes, there's no point in having this security daemon exist.

thanks for the possible solution, I agree about "efficiency"..

 

[Yota]

thanks for the possible solution, I agree about "efficiency"..

I edited my reply, there are obvious side effects of disabling and I wouldn't call it a solution for normal users, but for malware authors, yes it does disable all the protection provided by asd.

 

[zitev]

Az

I edited my reply, there are obvious side effects of disabling and I wouldn't call it a solution for normal users, but for malware authors, yes it does disable all the protection provided by asd.

I am convinced that this is only an appearance of protection, it does not provide a real solution, it only causes inconvenience to those who would otherwise take full advantage of the possibilities provided by the hardware. I simply shot down this scanner, so someone else can figure this out and block it as well.

 

[Yota]

Az

I am convinced that this is only an appearance of protection, it does not provide a real solution, it only causes inconvenience to those who would otherwise take full advantage of the possibilities provided by the hardware. I simply shot down this scanner, so someone else can figure this out and block it as well.

When almost all processes in the router are running as root, there's never real protection there because it's not a game of cat and mouse, all are equal.

I'm not a developer, but I did find a way to disable it, and for malware developers, I'm sure they could find a better way to disable it very quickly.

So I mean, such a process is not enough to deal with the threats, but it might block some known malware. however when malware authors actually spend their day working on Asuswrt, they laugh at such a process.

 

[zitev]

When almost all processes in the router are running as root, there's never real protection there because it's not a game of cat and mouse, all are equal.

I'm not a developer, but I did find a way to disable it, and for malware developers, I'm sure they could find a better way to disable it very quickly.

So I mean, such a process is not enough to deal with the threats, but it might block some known malware. however when malware authors actually spend their day working on Asuswrt, they laugh at such a process.

That's it, I'm glad you confirmed what I'm saying. However, from this point on, it is nothing more than an inconvenience, with which only the user of the product is punished.

 

[RMerlin]

It actually has no reason to scan the hdd, since no execute permissions should be allowed there.

Execution has to be allowed from USB disks, otherwise there would be no Entware, no Download Master, etc...

 

[Yota]

Execution has to be allowed from USB disks, otherwise there would be no Entware, no Download Master, etc...

Asuswrt can store these files to /jffs

Or refer to the method of Android using SD Card to expand internal storage:

When the SD Card is confirmed to be used as internal storage, it must be formatted. After formatting, the user will not be able to write to the SD Card, and it will become a part of the internal storage. Application data can be stored in it, and it is encrypted.

So when scanning is required, the system will only scan non-user partitions.

In fact when people install Entware, they format it. If the partition is no longer available to users after formatting, it is reasonable to scan it.

But for the partition where the user's documents are stored, I still insist that there shouldn't be any execute permissions there.

The Optware used by Download Master does not require the USB storage to be formatted, and also allows your documents and Optware to be in the same partition, for this they even allow 777 permissions on all files in fat32 format, which is the problem.



Honestly Asuswrt employs threat countermeasures that a lot of other brands of routers don't have but with more powerful hardware they should re-evaluate the current threat level because in my opinion these security holes and compromises for lower security threats are no longer enough to deal with current and future threats.

They had to redesign the firmware's security policy.

 

[brendanp]

I've had the same issue ... my USB2 connected hard disk has been spinning / seeking non-stop since the latest firmware upgrade - RT-AC68U v. 386.9.

The hard disk never goes into standby (as it used to) and it chugging away non-stop ... as this is in my home office, it's annoying to listen to, and makes me feel like it's eating into HDD life expectancy.

I have the same /usr/bin/find command running in my "top" output as well.

I'll try a roll-back to 386.7_2 and see if that resolves the issue ... this is certainly a new development on my router.

 

[brendanp]

Rolled back to 386.7_2; so far, silence! HDD spins down as it used to, and idles unless accessed by a computer on the network. the "asd" process is running, but no /usr/bin/find process grinding away ... I'll report back in a day in case it takes some time for that process to start; but so-far, so good!

 

[zitev]

Rolled back to 386.7_2; so far, silence! HDD spins down as it used to, and idles unless accessed by a computer on the network. the "asd" process is running, but no /usr/bin/find process grinding away ... I'll report back in a day in case it takes some time for that process to start; but so-far, so good!

I think it is temporarily sufficient if you manually suspend the running of the process, I don't think this "solution" will be long-lived (at least not for me).

 

[Yota]

@zitev @brendanp

Based on the mount method, I figured out a mitigation that doesn't have to kill asd -- disable find:

touch /tmp/replacefind && mount --bind /tmp/replacefind /usr/bin/find

This way asd can't call find and there will be no annoying scans.

But other "magical protections" provided by asd will still work.

For asd victims, time to spam asus! and hopefully they will reconsider asd behavior after receiving a lot of feedback.

EDIT:
Well, since find is just a symbolic link to busybox, doing this also disables busybox, and since mount/umount is also from busybox, you have to reboot the router to undo the change.

 

[brendanp]

For asd victims, time to spam asus! and hopefully they will reconsider asd behavior after receiving a lot of feedback.

I'm not sure it's an ASUS issue ... latest firmware on the ASUS site is dated July 22 ... I'm running Merlin firmware, and the 386.7_2 release was in July, and the 386.9 (which has this drive scanning "feature") was January 23.

 

[zitev]

@zitev @brendanp

Based on the mount method, I figured out a mitigation that doesn't have to kill asd -- disable find:

touch /tmp/replacefind && mount --bind /tmp/replacefind /usr/bin/find

This way asd can't call find and there will be no annoying scans.

But other "magical protections" provided by asd will still work.

For asd victims, time to spam asus! and hopefully they will reconsider asd behavior after receiving a lot of feedback.

EDIT:
Well, since find is just a symbolic link to busybox, doing this also disables busybox, and since mount/umount is also from busybox, you have to reboot the router to undo the change.

I described the problem on the Asus security form, but they dismissed me as not being a security problem, I should write to customer service. It's quite an arrogant attitude from them to cause a disturbing operation and I should even try to guide the error through the Asus system, instead of those who caused it dealing with it...

 

[zitev]

I'm not sure it's an ASUS issue ... latest firmware on the ASUS site is dated July 22 ... I'm running Merlin firmware, and the 386.7_2 release was in July, and the 386.9 (which has this drive scanning "feature") was January 23.

Do you think? Merlin said that he corresponded with asus about the matter and after that this was the solution (although personally I'm surprised that he also ported this hack to the merlin firmware.)

 

[brendanp]

Do you think? Merlin said that he corresponded with asus about the matter and after that this was the solution (although personally I'm surprised that he also ported this hack to the merlin firmware.)

He said that back in 2021 ... so asd has been in the Merlin product for years ... (in fact, asd shows in my "top" command presently) ... but the scanning of a mounded drive non-stop is something that only started in the latest 386.9 release.

 

[ColinTaylor]

I'm not sure it's an ASUS issue ...

It is an Asus issue. Merlin is using a more recent source code. asd is a closed source blob from Asus. Only they can fix it.