If the client accepts any certificate as a valid server's certificate, then an active attacker can impersonate the server when talking to the client.
If the attacker can steal a copy of the client's private key then he can impersonate the client when talking to the server.
If both conditions hold, then the attacker can run a successful Man-in-the-Middle attack, by definition: a MitM attack is nothing more than simultaneous double impersonation. The attacker poses as the client when talking to the server, and as the server when talking to the client; he relays traffic in both direction, inspecting and modifying data at will.
If the client can make sure that it uses the genuine server's certificate (either through validation from a known trusted root CA, or maybe because the client remembers the server's certificate from a previous connection), then the client will reject the impersonation attempt, and the MitM won't work. The attacker, who has stolen the client's private key, will still be able to replace the client, e.g. hijacking incoming calls, but that won't be a true MitM (the attacker will have to imitate the voice of the normal client's owner).
Note that if the attacker does not have a copy of the client's private key, and the server validates the client's public key in some way (e.g. the server remembers the client's public key after an initial configuration step), then the attacker will not be able to impersonate the client. Client authentication in SSL is such that even if the attacker impersonates the server, he cannot reuse the messages from a gullible client to fool the true server. Technically, the client uses his private key to sign a "challenge" which is a hash value computed over everything client and server have sent each other so far, and this includes the server's certificate; so, in case of MitM, the client will sign messages containing the attacker's public key (the fake server certificate sent by the attacker), not the certificate sent by the true server, and the signature will not match what the true server expects.
Therefore, if either the client can make sure that it uses the true server's certificate, or the server can make sure that it uses the true client's certificate, or both, then a complete MitM attempts must fail. However, even without a MitM, impersonation (an "half-MitM") is still possible:
- If the attacker steals the server's private key, or the client fails to validate the server's certificate, then the attacker can impersonate the server.
- If the attacker steals the client's private key, or the server fails to validate the client's certificate, then the attacker can impersonate the client.
Finally, if the attacker has a copy of the server's private key, and the SSL/TLS cipher suite is one of the non-DHE RSA suites, then the attacker can decrypt all the data after purely passive interception, and can also hijack the connection at any point after the handshake, which allows, again, a MitM. The same does not hold for a stolen client's private key; in SSL/TLS, the client certificate and private key are used only for authentication, not for the key exchange, and have no influence whatsoever on the resulting secret used for actual data encryption.