Fix #1394

[zst123]

This is the traceback of issue #1394 . The bug is in the standard library, ftplib.

2020-08-10T04:35:13+0000 [stderr#error] Traceback (most recent call last):
2020-08-10T04:35:13+0000 [stderr#error]   File "/cowrie/cowrie-git/src/cowrie/commands/ftpget.py", line 209, in ftp_download
2020-08-10T04:35:13+0000 [stderr#error]     ftp.connect(host=self.host, port=self.port, timeout=30)
2020-08-10T04:35:13+0000 [stderr#error]   File "/cowrie/cowrie-git/src/cowrie/commands/ftpget.py", line 39, in connect
2020-08-10T04:35:13+0000 [stderr#error]     self.welcome = self.getresp()
2020-08-10T04:35:13+0000 [stderr#error]   File "/usr/lib/python3.7/ftplib.py", line 236, in getresp
2020-08-10T04:35:13+0000 [stderr#error]     resp = self.getmultiline()
2020-08-10T04:35:13+0000 [stderr#error]   File "/usr/lib/python3.7/ftplib.py", line 222, in getmultiline
2020-08-10T04:35:13+0000 [stderr#error]     line = self.getline()
2020-08-10T04:35:13+0000 [stderr#error]   File "/usr/lib/python3.7/ftplib.py", line 213, in getline
2020-08-10T04:35:13+0000 [stderr#error]     elif line[-1:] in CRLF:
2020-08-10T04:35:13+0000 [stderr#error] TypeError: 'in <string>' requires string as left operand, not bytes

It does not occur on all FTP servers. It occurs only when the FTP server returns a byte message instead of a string. Ftplib expects a string and does not account for receiving a byte message.

This is a similar issue: ian-whitestone/khp-data#1
My pull request is the exact same as that fix. The modified ftplib will decode if needed instead of throwing an exception.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
No Duplication information

[micheloosterhof]

This is a problem upstream in Python. Maybe better to report it at https://bugs.python.org/ ?