momcilo | # 21 | 2011-06-15, 17:12 | Report

That is an assumption.

Here is the official OpenSSH link:
http://www.openssh.org/security.html

jedi | # 22 | 2011-06-15, 18:21 | Report

Using passwords sucks big time. To prevent against a scripted password-guessing bot, just disable password login on your N900 and only use keys.

edit (as root) /etc/ssh/sshd_config:
To use key based authentication: http://www.google.com/search?q=ssh+login+no+password


edit: woowoo post 1,000!

---

Last edited by jedi; 2011-06-15 at 18:23.

sr00t | # 23 | 2011-06-15, 18:29 | Report

Thanks a lot, Yoda, I'll lurk more about that.
1K get in my thread? What an honour .-

momcilo | # 24 | 2011-06-15, 18:46 | Report

I've just checked the freemantle repository.
Openssh is version 5.1p1

There are at least 3 published problems with security.

And OpenSSl is 0.9.8n, it also has 3 published issues.

Normally that would not be a severe problem given the use of the device. The herd logic dictates that the probability is low. But since you decided to enter the place where many lions seek food, your chances of getting eaten have risen significantly.

Good luck!

jedi | # 25 | 2011-06-15, 19:11 | Report

Please list the vulns for us

sr00t | # 26 | 2011-06-15, 19:24 | Report

If is this vuln, it's probably impossible to exploit it in a practical way:

http://www.openssh.org/txt/cbc.adv

momcilo | # 27 | 2011-06-15, 20:02 | Report

Once again, thank you for allowing me to correct my errors before completely disgracing myself.

Well after carefully reading the reported vulnerabilities (shame on me), it seems neither of the vulnerabilities is applicable to this particular case, or at lease probability is low as stated in:
http://www.openssh.com/txt/cbc.adv

As for openssl: this one may be applicable depending on how the package was built. The rest of them are related to server functionalities.

In any case, the point is that the "secure" is a very relative term that very often degrades over time.

Btw: Can someone check if there is a Comodo root certificate inside keystore within N900?

SSL redirection is still viable threat.
More info on: http://www.thoughtcrime.org/software/sslstrip/
That one actually works on wifi!!!

EDIT: Added more details and corrected errors

---

Last edited by momcilo; 2011-06-15 at 20:27.

momcilo | # 28 | 2011-06-15, 20:43 | Report

Well so far so good:
No Comodo or Honest Achmed within Diablo. (at least not for the built in browser/chat/e-mail)

As for N900, I don't own one so I can not check.

---

Last edited by momcilo; 2011-06-15 at 20:46.

fasza2 | # 29 | 2011-06-15, 21:00 | Report

Does our openvpn client have any known vulnerabilities?(let's assume the server is secure) Does HMAC auth apply to client as well as server? Can user/group nobody be set up on client side if server is not *NIX. Would chroot work client side only in the same scenario?

Is there any way to log keystrokes through a browser in N900?

Sandboxing Maemo's browsers?

Just some questions that I'd love to hear your opinion about.

---

Last edited by fasza2; 2011-06-15 at 21:05.

momcilo | # 30 | 2011-06-15, 21:41 | Report

You may want to check the openvpn page on that topic. But you can not eliminate the server as a factor.

A lot depends on the actual configuration of vpn server. In addition, there may be weaknesses in implementation as well as cryptography.

In brief:
OpenVPN uses TLS/SSL as transport protocol. When SSL session is established, two sides exchange public keys (certificates). By applying both keys to Diffie-Hellman authentication, the shared secret is computed. This shared secret is the symmetric key that is used for the symmetric cipher to transform the plain text to cipher text at the source, and later to transform the cipher text to plain text at the destination.

Please be more specific, because I am not sure if you are referring to the session establishment, or later integrity checks, when data are actualy sent?

By this you mean chroot-ing the openvpn client itself?

The posted exploit does not recover username/passwords from within browser. It basically replaces legitimate login page.

The attacker poses as a default router, by producing massive number of arp messages in order to confuse the victim about default gateways actual ARP address.

The attacker itself is configured to forward any incoming traffic to the legitimate router. The sslstrip is used in-between to replace unencrypted HTML login pages, with ones that can be used to log username/passwords.

Once the username/password is recovered, the information is used to create a legitimate session, so victim firmly belives it is secure, since the SSL is established and locker is visible.

---

Last edited by momcilo; 2011-06-15 at 21:43.