Live data from Hacker News

CloudFlare's Heartbleed challenge cracked

twitter.com

131–140 of 155 posts

Re: CloudFlare's Heartbleed challenge cracked

#131
post #89
post #32

Earlier quoted context omitted.

Also, cert revocation just barely works, in some browsers, with EV certificates, after old CRLs expire over a course of months: http://news.netcraft.com/archives/2013/05/13/how-certificate...

Is there a tutorial (for multiple browsers/platforms) for browser users to manually initiate downloading and processing of the latest CRL? Is this even exposed by most modern browsers, i.e. as part of the "clear cache" functionality? If so, I'd want to tell my [self/family/friends/coworkers] to do this in the coming weeks to minimize the amount of time they might happen to send private information to a MITM attacking…

Chrome doesn't check revocations by default. See "Check for server certificate revocation" in settings, which has for a while been disabled by default.

Re: CloudFlare's Heartbleed challenge cracked

#132
post #70

Earlier quoted context omitted.

>we had the bug 16 days early, no we had the bug 18 days early And we didn't know what to do about it... CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. OpenSSL has been patching variations of this bug for that whole time, and every good hacker, (and the bad ones) have been exploiting OpenSSL since its creation. https://www.openssl.org/news/secadv_20030930.txt People act surprised,…

> CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. Source?

CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability.

You won't find it on them. Their branch doesn't have the issue.

Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=opens...

You will see mentions of this bug in products that use OpenSSL quite often.

Re: CloudFlare's Heartbleed challenge cracked

#133
post #97

Earlier quoted context omitted.

CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. This isn't true. Don't make things up - this bug is bad enough without misinformation. OpenSSL has been patching variations of this bug for that whole time Untrue. OpenSSL has been patching unrelated bugs since it was created (as has most software). https://www.openssl.org/news/secadv_20030930.txt* This is unrelated to heartbleed.

It is related in that there has never been a release of OpenSSL that was secure. Not one. Ever. The known vulnerabilities list for OpenSSL has never had a release that didn't have a flaw that allowed some amount of "backdooring", Dataextraction, or data manipulation. (as opposed to just a path for a DoS attack) >Don't make things up - I don't have to make things up. The CIA and FBI keep a list of known vulnerabilitie…

So would you say Polar SSL is less likely to contain exploitable code?

Re: CloudFlare's Heartbleed challenge cracked

#134

Earlier quoted context omitted.

You now know the two primes (p,q) which multiply together to make n (the public key modulus). We also know e (the public key exponent). d (the private key) is:- d = e^-1 mod ((p-1)(q-1)) To work this modular inverse out you use the extended Euclidean algorithm. This is why you need to know the factorisation of n=(p*q). You can't compute d (the private key) with just the composite n.

You don't need to use p or q. See http://vnhacker.blogspot.com/2014/04/idea-to-solve-cloudflar...

apparently these temp values are scrubbed by openssl. i would definitely verify because there could be some implementation bug that stops their scrubbing. so what nginx does is:

  handle_request:
    do_decryption
    scrub_temporaries
    write_to_client
  handle_another_request:
    ..
because nginx is single threaded there shouldn't be any requests handled between do_decryption and scrub_temporaries. but this is a problem on other servers.

  static int RSA_eay_private_decrypt(int flen, const unsigned char *from,
               unsigned char *to, RSA *rsa, int padding)
          {
        ...

        if (ctx != NULL)
                {
                BN_CTX_end(ctx);
                BN_CTX_free(ctx);
                }
        if (buf != NULL)
                {
                OPENSSL_cleanse(buf,num);
                OPENSSL_free(buf);
                }
        return(r);


  void BN_CTX_free(BN_CTX *ctx)
        {
        if (ctx == NULL)
                return;
  #ifdef BN_CTX_DEBUG
        {
        BN_POOL_ITEM *pool = ctx->pool.head;
        fprintf(stderr,"BN_CTX_free, stack-size=%d, pool-bignums=%d\n",
                ctx->stack.size, ctx->pool.size);
        fprintf(stderr,"dmaxs: ");
        while(pool) {
                unsigned loop = 0;
                while(loop vals[loop++].dmax);
                pool = pool->next;
        }
        fprintf(stderr,"\n");
        }
  #endif
        BN_STACK_finish(&ctx->stack);
        BN_POOL_finish(&ctx->pool);
        OPENSSL_free(ctx);
        }


  static void BN_POOL_finish(BN_POOL *p)
          {
          while(p->head)
                  {
                  unsigned int loop = 0;
                  BIGNUM *bn = p->head->vals;
                  while(loop++ d) BN_clear_free(bn);
                          bn++;
                          }
                  p->current = p->head->next;
                  OPENSSL_free(p->head);
                  p->head = p->current;
                  }
          }


  void BN_clear_free(BIGNUM *a)
          {
          int i;

          if (a == NULL) return;
          bn_check_top(a);
          if (a->d != NULL)
                  {
                  OPENSSL_cleanse(a->d,a->dmax*sizeof(a->d[0]));
                  if (!(BN_get_flags(a,BN_FLG_STATIC_DATA)))
                          OPENSSL_free(a->d);
                  }
          i=BN_get_flags(a,BN_FLG_MALLOCED);
          OPENSSL_cleanse(a,sizeof(BIGNUM));
          if (i)
                  OPENSSL_free(a);
          }

  void OPENSSL_cleanse(void *ptr, size_t len)
          {
          unsigned char *p = ptr;
          size_t loop = len, ctr = cleanse_ctr;
          while(loop--)
                  {
                  *(p++) = (unsigned char)ctr;
                  ctr += (17 + ((size_t)p & 0xF));
                  }
          p=memchr(ptr, (unsigned char)ctr, len);
          if(p)
                  ctr += (63 + (size_t)p);
          cleanse_ctr = (unsigned char)ctr;
          }

Re: CloudFlare's Heartbleed challenge cracked

#135

Earlier quoted context omitted.

It is related in that there has never been a release of OpenSSL that was secure. Not one. Ever. The known vulnerabilities list for OpenSSL has never had a release that didn't have a flaw that allowed some amount of "backdooring", Dataextraction, or data manipulation. (as opposed to just a path for a DoS attack) >Don't make things up - I don't have to make things up. The CIA and FBI keep a list of known vulnerabilitie…

So would you say Polar SSL is less likely to contain exploitable code?

It seems to have a history of having fewer exploits that can result in leaking data. It has had more DoS exploits (I think) but most of them could be mitigated through configuration.

I think that the revenue model for Polar has put more money in to making sure it is secure. OpenSSL has always suffered from the fact that it is mostly "leach Ware". People use but they don't contribute because it isn't related to their core competency, so they don't mod or upgrade it. Polar on the other hand has people paid to test, patch and maintain the code.

Re: CloudFlare's Heartbleed challenge cracked

#136
post #43

Considering he just pulled a shadow file as well, it's not pretty.

I think someone else found that, although he linked to their pic. Remember, lots of people are pushing up bogus stuff into the heap, so just because you see something there doesn't mean Cloudflare leaked it.

And who runs their webserver as root? (Or who changes the permissions on /etc/shadow to allow it be read by a non-root process).

Having to be root to be able to bind to a TCP port <1024 is no longer necessary on a modern OS.

Re: CloudFlare's Heartbleed challenge cracked

#137

Earlier quoted context omitted.

> CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. Source?

CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability. You won't find it on them. Their branch doesn't have the issue. Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=opens... You will see mentions of this bug in products that use OpenSSL quite often.

haven't seen a mention of it yet.

Re: CloudFlare's Heartbleed challenge cracked

#139

Earlier quoted context omitted.

> CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. Source?

CIA and FBI servers are easy to find, and many run OpenSSL. Go see which ones have the vulnerability. You won't find it on them. Their branch doesn't have the issue. Also look through this http://web.nvd.nist.gov/view/vuln/search-results?query=opens... You will see mentions of this bug in products that use OpenSSL quite often.

Do you have evidence of that being true a week ago? It's no surprise that the CIA and FBI would scramble to lock down vulnerabilities as soon as they were announced, but that's not proof that they never had them in the first place.

After the Snowden business, I wouldn't be hugely surprised if the gov't was secretly aware of Heartbleed, but I'm not comfortable taking a random stranger's word for it.

Re: CloudFlare's Heartbleed challenge cracked

#140
post #97
post #70

Earlier quoted context omitted.

>we had the bug 16 days early, no we had the bug 18 days early And we didn't know what to do about it... CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. OpenSSL has been patching variations of this bug for that whole time, and every good hacker, (and the bad ones) have been exploiting OpenSSL since its creation. https://www.openssl.org/news/secadv_20030930.txt People act surprised,…

CIA and FBI had knowledge of variations of this vulnerability nearly 10 years ago. This isn't true. Don't make things up - this bug is bad enough without misinformation. OpenSSL has been patching variations of this bug for that whole time Untrue. OpenSSL has been patching unrelated bugs since it was created (as has most software). https://www.openssl.org/news/secadv_20030930.txt* This is unrelated to heartbleed.

Yup, the threat horizon for Heartbleed only starts at March 14, 2012 with the first release of OpenSSL 1.0.1.

http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1-released-td3...

Post reply on HN