taskd vulnerable to port scan/DOS attack (no socket timeout implemented)

[jose1711]

I am syncing my tasks to a remote instance of taskwarrior, running on port 50000 and properly secured. However I have found that from time to time I need to restart the daemon as the sync randomly stops working (Sync failed. Could not connect to the Taskserver.). Recently I've been digging a bit more to find out that there is a direct connection with suspicious IP, often reported at sites like https://www.abuseipdb.com/. During the times when the service is unavailable, the situation on the server appears as follows:

$ netstat -an | grep 50000
tcp       11      0 taskwarrior_server_ip:50000     0.0.0.0:*       LISTEN     
tcp      397      0 taskwarrior_server_ip:50000     my_ip:39528     CLOSE_WAIT 
tcp        0      0 taskwarrior_server_ip:50000     suspicious_ip:40070     ESTABLISHED
tcp      397      0 taskwarrior_server_ip:50000     my_ip:40670     CLOSE_WAIT 
tcp      397      0 taskwarrior_server_ip:50000     my_ip:51002     CLOSE_WAIT 
tcp      397      0 taskwarrior_server_ip:50000     my_ip:47096     CLOSE_WAIT 

Until the service is restarted I am seeing a stream of TCP retransmission originating from my IP address:

Could it be that a TCP connection opened for several hours results in such a condition?

Taskd is 1.1.0 running on Debian sid.

Edit:
Actually it turns out it's very easy to reproduce the issue. In one terminal run:

telnet taskwarrior_ip 50000

and leave the session opened. In second terminal try to sync. The sync is blocked until the previous TCP session is terminated.

[jose1711]

Related to GothenburgBitFactory/taskwarrior#2987

[djmitche]

Just to clarify for anyone else reading this: taskd (the taskwarrior sync server) is vulnerable. Taskwarrior itself is not.

Until there's a better sync server available, the best recommendation is to limit access to the taskserver as much as possible.

[jose1711]

Just to clarify for anyone else reading this: taskd (the taskwarrior sync server) is vulnerable. Taskwarrior itself is not.

Until there's a better sync server available, the best recommendation is to limit access to the taskserver as much as possible.

Thank you, I improved the title based on your comment.

[jose1711]

As a matter of fact this (and the referenced issues) should be moved under https://github.com/GothenburgBitFactory/taskserver/issues - could that be done by the repo owner or I need to recreate it manually?

[djmitche]

I can do that!

[djmitche]

Oh, I can't - I'm a repo admin, not an org admin. Maybe @lauft or @tbabej can help?

[tbabej]

Yep! Moving over to taskserver.

[btwe]

I run taskd 1.2.0 on debian for quite some time and do not face DDOS issues. But that's only my experience, so be warned by the comments above.

OTOH, the reason why I comment here is, that this issue report reminds me about my todo. My plan is to finally remove my taskd.service and switch over to syncthing to keep taskwarrior files synched across my devices. I also wanted to suggest this here. I think this might be a good solution for others as well.

[LeGuipo]

I come from the other way. If you have multiple devices it’s much more comfortable to manage task updates without overwriting everything and potentially loose some forgotten modifications done on some less used device. I can’t go back to file syncing. Meanwhile, my server’s firewall is set to restrict taskd access from unspecified sources, that will do most the job.

[lauft]

Important

Taskserver is only compatible with Taskwarrior 2.x, and is no longer actively developed.
See man task-sync for task synchronization with Taskwarrior 3