What is "asd" process?

[Mogsy]

Interesting reads. I wonder if this has connection to iOS’

/usr/libexec/asd

Not knowing Linux (learning) it described on Linux FHS guide

I have a few diskwrite log for this /usr path on iOS 16.2

 

[zitev]

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.

I wonder what's up with the latest asus firmware? does the scanner also run on it?

 

[brendanp]

Update: 12 hours post roll-back, and my HDD is idle as expected...for me: rolling back to Merlin 386.7_2 is the "fix" for now.

 

[zitev]

Update: 12 hours post roll-back, and my HDD is idle as expected...for me: rolling back to Merlin 386.7_2 is the "fix" for now.

...and the other working solution is the one I also wrote: suspending the running process. This obviously has to be done again after every reboot, but it seems manageable for now.

 

[brendanp]

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.

"ASUS customer support, how can I help you?"
"Yes, my router is scanning my HDD non-stop since a firmware upgrade..."
"What version are you running sir?"
"Merlin 386.9"
" 'Merlin'? So you're not running stock ASUS firmware?"
"Well, no, but ..."
<click>

 

[ColinTaylor]

"ASUS customer support, how can I help you?"
"Yes, my router is scanning my HDD non-stop since a firmware upgrade..."
"What version are you running sir?"
"Merlin 386.9"
" 'Merlin'? So you're not running stock ASUS firmware?"
"Well, no, but ..."
<click>

So what's your point?

 

[brendanp]

So what's your point?

My point is: Reporting abnormal behavior of a non-ASUS firmware (e.g. Merlin) to ASUS is a non-starter.

 

[zitev]

My point is: Reporting abnormal behavior of a non-ASUS firmware (e.g. Merlin) to ASUS is a non-starter.

the question is, is this malfunction specific to Merlin firmware only, or did it occur with Asus firmware as well?

 

[ColinTaylor]

My point is: Reporting abnormal behavior of a non-ASUS firmware (e.g. Merlin) to ASUS is a non-starter.

True. And complaining about something in the Merlin forum that is outside the developer's control is equally pointless. So the people that this is a problem for can choose to stay on the previous release until Asus fixes it. In the meantime people running stock firmware (now or in the future) that experience this problem can report it to Asus.

 

[zitev]

True. And complaining about something in the Merlin forum that is outside the developer's control is equally pointless. So the people that this is a problem for can choose to stay on the previous release until Asus fixes it. In the meantime people running stock firmware (now or in the future) that experience this problem can report it to Asus.

the only question is which is the bigger security problem, an older firmware, possibly containing sechole, or a new firmware, which must block running processes in order to avoid malfunctions...

 

[brendanp]

True. And complaining about something in the Merlin forum that is outside the developer's control is equally pointless. So the people that this is a problem for can choose to stay on the previous release until Asus fixes it. In the meantime people running stock firmware (now or in the future) that experience this problem can report it to Asus.

I disagree. "Complaining" about this problem has yielded not 1 but 2 good work-arounds. (And possibly more will follow).

Users who experience the same issue can find this thread via Google (as I did) and quickly confirm, "Yes, that's what's happening to me ... " and have solutions provided.

 

[brendanp]

the only question is which is the bigger security problem, an older firmware, possibly containing sechole, or a new firmware, which must block running processes in order to avoid malfunctions...

To be honest: The only reason I upgraded was to get rid of the blinky-"!" saying there was a new version available. I didn't have a particular security hole I was trying to patch or anything. So Rolling back is my personal preferred solution. It's easier, only needs to be done once, and survives a power-outage ... so for my use-case, that works. If you have benefits from the latest release that you need; then I think you're solution is great ... maybe somebody with more knowledge than me could even figure out how to script it at boot. Is the INIT process consuming CPU now trying to restart the /usr/bin/find process? Or is it still "running" but "suspended" with your solution?

 

[zitev]

Or is it still "running" but "suspended" with your solution?

it is completely suspended, there is no running "find' process..

 

[brendanp]

it is completely suspended, there is no running "find' process..

Do you have INIT consuming 50% CPU trying to restart the asd process (as described in post #44)?

 

[zitev]

Do you have INIT consuming 50% CPU trying to restart the asd process (as described in post #44)?

no, the process is only suspended, not stopped (if i stop, then it starts again immediately)

 

[dabbleduck]

There is a bigger problem with asd then just hammering attached drives with scans. asd is actually destructive. I mounted an nfs share that contained some fortunately now unused nfsroot filesystems. asd scanned them and deleted all files of the form crt*. This makes asd seem like a rather blunt instrument. All these files on the mount were either i686 or x86_64 binaries, which could not have been used to link executables that would run on the router. Sure, these files could be used to link malware on other machines, but how hard would it be to store these C runtime files using a different name. I would never have known about this if I hadn't tried to unmount the share and had the request denied because asd had open files on it. If I remember correctly, asuswrt by default will mount a usb drive when it is plugged in. So if someone plugged in a drive containing a linux system, asd would damage it, possibly without anyone knowing until much later. Based on this as far as I am concerned, even though asd is supposed to be antimalware software, it is malware. Fortunately SIGSTOP works for me with 386.9 on an RT-AC68U. I did not lose anything important, but my trust in Asus has been shaken. What else is this binary blob looking for? Asuswrt-Merlin may want to reevaluate their position on asd.

 

[brendanp]

There is a bigger problem with asd then just hammering attached drives with scans. asd is actually destructive. I mounted an nfs share that contained some fortunately now unused nfsroot filesystems. asd scanned them and deleted all files of the form crt*.

Yikes! No quarantine or logs to tell you what files were impacted / deleted? asd simply goes in and deletes files it doesn't like? That is the exact definition of malware!

 

[dabbleduck]

There was a log in /jffs/asd.log as the following excerpt shows.

...
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crtn.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crtn.o is binary.
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crti.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crti.o is binary.
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crt1.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crt1.o is binary.
...

But I did not even know the asd process existed until this happened, and how many people expect a reasonably well protected router to just start deleting files from a mount? If the files were quarantined, there is nothing in the log to indicate that.

 

[D0m3L]

There is a bigger problem with asd then just hammering attached drives with scans. asd is actually destructive. I mounted an nfs share that contained some fortunately now unused nfsroot filesystems. asd scanned them and deleted all files of the form crt*. This makes asd seem like a rather blunt instrument. All these files on the mount were either i686 or x86_64 binaries, which could not have been used to link executables that would run on the router. Sure, these files could be used to link malware on other machines, but how hard would it be to store these C runtime files using a different name. I would never have known about this if I hadn't tried to unmount the share and had the request denied because asd had open files on it. If I remember correctly, asuswrt by default will mount a usb drive when it is plugged in. So if someone plugged in a drive containing a linux system, asd would damage it, possibly without anyone knowing until much later. Based on this as far as I am concerned, even though asd is supposed to be antimalware software, it is malware. Fortunately SIGSTOP works for me with 386.9 on an RT-AC68U. I did not lose anything important, but my trust in Asus has been shaken. What else is this binary blob looking for? Asuswrt-Merlin may want to reevaluate their position on asd.

And unfortunately I do confirm this. Everything matching the following patterns have been removed from NAS mounted to /tmp/mnt/

/usr/bin/find /tmp -iname .config_read*
/usr/bin/find /tmp -iname cpd*
/usr/bin/find /tmp -iname crrt*
/usr/bin/find /tmp -iname crt*

There are also other scans on /tmp and /jffs/

/usr/bin/find /jffs/tmp -iname directory
/usr/bin/find /jffs/configs -iname ssl
/usr/bin/find /tmp/logs -iname WGUpgrade-dl
/usr/bin/find /tmp/ppp -iname S51armled
/usr/bin/find /tmp/var -iname link

You can find detailed info on what was removed in /jffs/asd.log, e.g.:

1674250019[remove_file_in_dir]Delete harmful file,/tmp/mnt/nas_backup/lib/crt_important-file.o
1674250081[remove_file_in_dir]Delete harmful file,/tmp/mnt/nas_backup/lib/crrt_important-file.o

Keep you software up to date, to keep your network and data safe, they say...

 

[zitev]

There was a log in /jffs/asd.log as the following excerpt shows.

...
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crtn.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crtn.o is binary.
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crti.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crti.o is binary.
1674212880[remove_file_in_dir]Delete harmful file,/tmp/mnt/irrigation-32/usr/lib/crt1.o
1674212880[blockfile] /tmp/mnt/irrigation-32/usr/lib/crt1.o is binary.
...

But I did not even know the asd process existed until this happened, and how many people expect a reasonably well protected router to just start deleting files from a mount? If the files were quarantined, there is nothing in the log to indicate that.

this is such a primitive solution that it is outrageous...