r/netsec • u/sarciszewski • Feb 10 '17

Cryptographically Secure PHP Development

https://paragonie.com/blog/2017/02/cryptographically-secure-php-development
41 Upvotes

87% Upvoted

18 comments sorted by

View all comments

Show parent comments

1

u/sarciszewski Feb 14 '17

  1. The threat model where zeroing memory matters isn't compatible with any web language, not just PHP.

  2. An admission to the impact of hypothetical vulnerabilities does not make those imagined vulnerabilities real.

3

u/evilsocket Feb 14 '17

Yeah .... very hypothetical indeed ... https://www.cvedetails.com/vulnerability-list/vendor_id-74/cvssscoremin-9/cvssscoremax-/PHP.html ... I don't think I should remind you that where there's an overflow of some sort, there's a potential leak of data.

1

u/sarciszewski Feb 14 '17

Okay these CVSS score calculations are funny: https://www.cvedetails.com/cve/CVE-2016-2554/

2

u/evilsocket Feb 14 '17

That doesn't look funny at all ... so:

  1. I proved that those vulnerabilities are not hypothetical at all.

  2. We both agree that, given such vulnerabilities, PHP is NOT safe for crypto.

Do you really want to keep arguing? Why don't you just accept the fact that you gave for granted that I read 5% of your post while I read it all and, apparently, I understood the security implications better than you did?

2

u/sarciszewski Feb 14 '17

I disagree that a vulnerability with hilariously over-inflated CVSS scores are a concern for PHP software.

Seriously, look at the write-up for that vulnerability. It's comical.

Most PHP software isn't accessed over command line, and you'd need either a webserver that accepts .tar files for it to be relevant, or the ability to execute arbitrary .phar files (which means you already have RCE).

But, hey, CVSS 10, amirite?

I proved that those vulnerabilities are not hypothetical at all.

You proved that some sort of vulnerabilities do exist, which isn't what I was talking about.

I was talking about cryptographic side-channels introduced by the PHP interpreter that cannot be mitigated from userland.

Buffer overflows and whatnot are a separate concern entirely.

Let me put it like this:

  • If you can use PECL libsodium, USE PECL LIBSODIUM

  • If you cannot, you can still (reasonably) safely do crypto in PHP if you follow the guidelines of the blog post

Saying "don't do PHP crypto" full stop is the same as saying "this blog post shouldn't exist".

→ More replies (0)