Hi, below please find is an analysis about deficits in the current implementation of pysocket SSL. pysocket is vulnerable to the following attacks:
1) Spoofing of server address 2) Intercepting an existing, encrypted connection 3) Silently switching from SSL to non-SSL 4) Very first connection vulnerable to spoofing 5) Conclusion and solution This analysis is based on codereview for issue223066, patchset 2. 1) Spoofing of server even if server uses SSL ---------------------------------------------------- If an attacker spoofs the server address and does not offer SSL communication, the client will simply talk unencrypted to the attacker's server. Since SSL is not used, the identity of the server can not be checked be the client. Reason: The client leaves the decision, whether SSL is to be used, to the server. Rationale: Following the control flow in pysocket.py shows: The client opens a connection to the server. Then it tries to open a SSL connection. If this fails, the client will not use SSL, thus will not check the servers identity. Vulnerable: fingerprint, certificates Solution: The client has to decide whether he wants to use SSL. 2) Intercepting an existing, encrypted connection --------------------------------------------------------- An attacker may intercept an existing, encrypted connection by simply spoofing the server address. Spoofing the address will break the connection, but the client will reestablish it while talking to the attacker's server. If the attacker's server is not offering SSL, the client does not check the servers identity (see above) and talk to the attacker's server. Reason: The client falls back to non-SSL even if the connection has been established as SSL earlier. Rationale: Following the control flow in netrpc.py and pysocket.py shows: If the SSL connection is broken, the client tries to reestablish it (which is a good thing). Now talking to the attacker's server, which does not offer SSL, the identity of the server is not checked (see above). Vulnerable: fingerprint, certificates Solution: The client has to remember whether the connection uses SSL at least until the user logs out and must not fall back to non-SSL. 3) Silently switching from SSL to non-SSL -------------------------------------------- If the server is offering SSL but then restarted with SSL set to off, the client silently switches from SSL to non-SSL. In this case a) the user does not get any notification about the change. Only the "Lock" icon in the lower right corner of the main window will vanish. But this is overlooked very easy (as experiences from web-browsers show). b) data is transmitted anyway. Reason: see 2) Rationale: Following the control flow in netrpc.py and pysocket.py shows: If the SSL connection is broken, the client tries to reestablish it. Now the server does not offer SSL anymore, the client uses non-SSL connection. Then the data is sent without notifying the user about of the change. *After* the data has been sent and the result has been received, the "lock" icon is removed. One may argue, if the real server is switching from SSL to non-SSL, this requires admin interaction and thus should be okay. But if SSL connection has been configured first, there is barely no reason to switch to non-SSL -- especially within working hours. Thus if this switch occurs, it is a big, big sign that something nasty is going on. This may be as simple as a server configuration error. But nevertheless: With a chance o 1:100000 something happened that should not happen. Vulnerable: fingerprint, certificates Solution: Notifying the user (e.g. showing some warning requester) is not a solution, since the user will simply click "okay" (since he wants to do his job, as experience shows). So: The client has to remember whether the connection uses SSL at least until the user logs out and must not fall back to non-SSL. 4) Very first connection vulnerable to spoofing ----------------------------------------------------- When the client is talking to a server the very first time, this servers fingerprint is saved for further connections. If at this moment the client is talking to spoofed server, the spoofed server's fingerprint is saved. So nobody recognises that the client is talking to the attacker's server from the very beginning. Reason: The client silently saves the fingerprint for new connections without either checking the identity of the server nor requesting the user to conform the fingerprint. NB: SSH by default asks the user. Rationale: Following the control flow in netrpc.py, pysocket.py and fingerprint.py shows: For a new host, the fingerprint is saved silently. Vulnerable: fingerprint Solution: Add new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do. Alternatively find another way to check the server identity. 5) Conclusion and solution ----------------------------- Issues 2 and 3 are easily to be solved: The client has to remember whether the connection uses SSL. Issue 1 is easily to be solved: The client has to decide whether he wants to use SSL. Issue 4 requires some more work: fingerprint.py requires some kind of call back to the GUI to ask the user for confirmation. The solution for issues 1, 2 and 3 are already implemented in <http://codereview.appspot.com/181110/show>. Since issue181110 has changes in some more modules and deeper changes than issue223066, I propose merging issue223066 into issue181110. issue181110 is currently missing fingerprint and certificate check, but these are easy to integrate. If issue181110 is accepted, I volunteer for back-porting it to 1.4. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult mit Mitglied bei http://www.7-it.de
smime.p7s
Description: S/MIME Cryptographic Signature
