0

perhaps all of us use no-Script when we visit untrusted web pages to block all scripts plugins etc. but still there is something beside plain HTML codes that we don't block; SSL connection! in Https protocol any web page can send crypto data to us which is handled by Firefox NSS lib and its almost always based on two thing, AES and RSA. from my opinion Encrypting or Decrypting received data from untrusted site must be safe because crypto libs are not like a flash player that give ability to attacker to make endless possible codes and run.. for example in AES its just processing each byte with a few known cycles to encrypt it or decrypt it and both are almost same and in RSA its just a math function on a number, why should calculating numbers cause a buffer-overflow? the question is :

  • is that possible make a compromise with AES encryption / decryption ?
  • is that possible make a compromise with RSA decryption (if attacker know private key or don't know)
user20876
  • 1
  • 4
    I don't understand what you are asking. HTTPS should be enough, and its its not enough you are almost certainly doing something wrong. – rook Feb 17 '13 at 17:25
  • 2
    Remote code execution vulnerabilities can be in any part of the browser. Be it the image renderer, the SSL library (ASN1 parsers are a prime candidate), or the javascript engine. – CodesInChaos Feb 17 '13 at 17:38

3 Answers3

5

Cryptographic algorithms are not interpreters for a Turing-equivalent language. As such, they cannot be meaningfully compared with scripting support, which Noscript deactivates.

Implementations of cryptographic algorithms are rarely afflicted with buffer overflows, but may leak some highly sensitive data (such as cryptographic keys) if inexpertly implemented. A more usual source of vulnerabilities is the handling of X.509 certificates (e.g. see this for OpenSSL), because decoding of certificates can be a daunting task due to its (ab)use of all the intricacies of ASN.1.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
2

You are asking if it is possible to find a flaw in the SSL mechanism, so that you can run an exploit on a victim computer.

This is highly unlikely, the purpose of the encrypted connection is clear and the implementation is also tested and quite strict.

If the other end does not speak SSL and it says it does, then the browser will cut the connection as soon as something is not right.

As soon as you check that you are on the right domain and that it has a valid certificate, you should be safe in most of the cases (excepting the case when both a DNS server and a certificate authority are compromised).

Dinu
  • 3,166
  • 14
  • 25
0

To give you a clear short answer: Yes, in theory it is possible to be compromised by just visiting view-source:http s://attacker.in.

However most crypto has lot of focus on error handling (e.g. someone tampering with the encrypted stream shouldn't learn anything about the cleartext), so just like the others, I think it's highly unlikely that any (exploitable) flaw exist in this part of the code.

An attacker could also find a flaw in image/css-rendering or maybe bypass NoScript with some kind of smart mixed charset (while NoScript is awesome(!!), then it's not 100% perfect - nothing is).

Nicolai
  • 131
  • 4