New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no suitable CSPRNG 1.3.0 #99

Closed
menkaff opened this Issue Mar 18, 2016 · 29 comments

Comments

Projects
None yet
9 participants
@menkaff

menkaff commented Mar 18, 2016

i'm getting error when upgrade to 1.3.0
Error : There is no suitable CSPRNG installed on your system on random.php file
my desktop ubuntu is PHP 7.0.4 and the Server PHP is 5.6 , i'm using random_compact in laravel 5.1
i can not fix it on Server so downgrade to 1.2.2
but on on my desktop everything is ok :)

@geggleto

This comment has been minimized.

Show comment
Hide comment
@geggleto

geggleto Mar 18, 2016

Well in 1.3 the choice was made to not support openssl.
You should look at the release notes for 1.3.x here https://github.com/paragonie/random_compat/releases

There is a workaround provided in the release notes.

geggleto commented Mar 18, 2016

Well in 1.3 the choice was made to not support openssl.
You should look at the release notes for 1.3.x here https://github.com/paragonie/random_compat/releases

There is a workaround provided in the release notes.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

Hi.

Please check the version 1.3.0 release notes. We removed OpenSSL in 1.3.0 due to a preponderance of concerns over its reliability as a secure provider of random data.

While downgrading to 1.2.2 is probably fine, your application would be far more secure if you made sure it could work with 1.3.0 instead. Can I ask:

  • What OS are you running?
  • Do you have open_basedir enabled?
  • Are you running in, e.g. a FreeBSD jail? (If so, you need access to /dev/urandom.)
Member

paragonie-scott commented Mar 18, 2016

Hi.

Please check the version 1.3.0 release notes. We removed OpenSSL in 1.3.0 due to a preponderance of concerns over its reliability as a secure provider of random data.

While downgrading to 1.2.2 is probably fine, your application would be far more secure if you made sure it could work with 1.3.0 instead. Can I ask:

  • What OS are you running?
  • Do you have open_basedir enabled?
  • Are you running in, e.g. a FreeBSD jail? (If so, you need access to /dev/urandom.)
@menkaff

This comment has been minimized.

Show comment
Hide comment
@menkaff

menkaff Mar 18, 2016

actually it is not s VPS or VDS , it is a very limited shared host , i think it is debian , open_basedir is enable and i do not have access /dev/urandom
i'm sorry i forgot to read release notes. and i think removed OpenSSL make it more secure 👍

menkaff commented Mar 18, 2016

actually it is not s VPS or VDS , it is a very limited shared host , i think it is debian , open_basedir is enable and i do not have access /dev/urandom
i'm sorry i forgot to read release notes. and i think removed OpenSSL make it more secure 👍

@menkaff menkaff closed this Mar 18, 2016

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

Can you contact your shared host and request access to /dev/urandom?

Member

paragonie-scott commented Mar 18, 2016

Can you contact your shared host and request access to /dev/urandom?

@Miliooo

This comment has been minimized.

Show comment
Hide comment
@Miliooo

Miliooo Mar 18, 2016

Same problem here, imo this should not have been a 1.3 release but a 2.0 release.
Symfony form 2.8 relies on this component and it updated to the 1.3 version.

This worked fine on my test local server, but my hosting server has no access to dev/urandom.
A quick fix is to rely on "paragonie/random_compat": "1.2" in your composer.json file

Miliooo commented Mar 18, 2016

Same problem here, imo this should not have been a 1.3 release but a 2.0 release.
Symfony form 2.8 relies on this component and it updated to the 1.3 version.

This worked fine on my test local server, but my hosting server has no access to dev/urandom.
A quick fix is to rely on "paragonie/random_compat": "1.2" in your composer.json file

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Mar 18, 2016

I'm kind of regretting recommending this to be a 1.3 release. It's biting us in the ass on laravel too.

GrahamCampbell commented Mar 18, 2016

I'm kind of regretting recommending this to be a 1.3 release. It's biting us in the ass on laravel too.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

OK, then, I'm going to do this:

  1. Release 1.4 with OpenSSL restored.
  2. Release 2.0 without OpenSSL.

Sound like a plan?

Member

paragonie-scott commented Mar 18, 2016

OK, then, I'm going to do this:

  1. Release 1.4 with OpenSSL restored.
  2. Release 2.0 without OpenSSL.

Sound like a plan?

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell commented Mar 18, 2016

👍

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

The above plan made sense to me, so I executed it. (I had a feeling that v2.0.0 was the most likely outcome when I posted this.)

Sorry for any inconvenience this caused anyone (on a Friday, no less). The solution should be a composer update away.

Member

paragonie-scott commented Mar 18, 2016

The above plan made sense to me, so I executed it. (I had a feeling that v2.0.0 was the most likely outcome when I posted this.)

Sorry for any inconvenience this caused anyone (on a Friday, no less). The solution should be a composer update away.

@Miliooo

This comment has been minimized.

Show comment
Hide comment
@Miliooo

Miliooo Mar 18, 2016

symfony/polyfill-php70 relies on this component. So while doing a composer update it updated to the 1.3 version. I guess it's used for CSRF form tokens. This made every form page return a 500 error.

So I guess that package should be responsible for relying on the 2.0 version with the workaround? Or alternatively updating the symfony requirements check?

I have my own dedicated server, but I find very little information about how to make /dev/urandom readable

Miliooo commented Mar 18, 2016

symfony/polyfill-php70 relies on this component. So while doing a composer update it updated to the 1.3 version. I guess it's used for CSRF form tokens. This made every form page return a 500 error.

So I guess that package should be responsible for relying on the 2.0 version with the workaround? Or alternatively updating the symfony requirements check?

I have my own dedicated server, but I find very little information about how to make /dev/urandom readable

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

Update to 1.4.0 or if you don't trust OpenSSL (I don't), upgrade to 2.0.0.

Member

paragonie-scott commented Mar 18, 2016

Update to 1.4.0 or if you don't trust OpenSSL (I don't), upgrade to 2.0.0.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 18, 2016

Member

I'm havind my own dedicated server, but I find very little information about how to make /dev/urandom readable

var_dump(ini_get('open_basedir'));

If that's not empty, edit your php.ini file and add :dev at the end of your configuration directive for PHP.

Member

paragonie-scott commented Mar 18, 2016

I'm havind my own dedicated server, but I find very little information about how to make /dev/urandom readable

var_dump(ini_get('open_basedir'));

If that's not empty, edit your php.ini file and add :dev at the end of your configuration directive for PHP.

@narfbg

This comment has been minimized.

Show comment
Hide comment
@narfbg

narfbg Mar 18, 2016

:/dev, with the slash.

narfbg commented Mar 18, 2016

:/dev, with the slash.

@Miliooo

This comment has been minimized.

Show comment
Hide comment
@Miliooo

Miliooo Mar 18, 2016

Well now I have this problem:
composer/composer#680

If i want to enable open_basedir i have to whitelist a lot of folders. Doesn't feel very secure to me... But I have no clue what I'm doing.

Miliooo commented Mar 18, 2016

Well now I have this problem:
composer/composer#680

If i want to enable open_basedir i have to whitelist a lot of folders. Doesn't feel very secure to me... But I have no clue what I'm doing.

@narfbg

This comment has been minimized.

Show comment
Hide comment
@narfbg

narfbg Mar 18, 2016

You're not supposed to enable it just to whitelist /dev/urandom ... it's the other way around - if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

narfbg commented Mar 18, 2016

You're not supposed to enable it just to whitelist /dev/urandom ... it's the other way around - if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

@Miliooo

This comment has been minimized.

Show comment
Hide comment
@Miliooo

Miliooo Mar 18, 2016

if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

@narfbg thanks I fixed it, it was enabled although my php.ini had it commented out. I'm still using directadmin and that has a php configuration page where you can enable or disable open basedir for each domain. I forgot to check that one.

So i commented out the open_basedir setting in my php.ini, disabled it in directadmin, and now i seem to be able to run 1.3 just fine.

Miliooo commented Mar 18, 2016

if it is already enabled, it may be what's preventing you from accessing /dev/urandom.

@narfbg thanks I fixed it, it was enabled although my php.ini had it commented out. I'm still using directadmin and that has a php configuration page where you can enable or disable open basedir for each domain. I forgot to check that one.

So i commented out the open_basedir setting in my php.ini, disabled it in directadmin, and now i seem to be able to run 1.3 just fine.

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Mar 19, 2016

Contributor

why drop openssl completely, isn't it fixed in later php versions? rather compare php version? or do some feature test?

Contributor

glensc commented Mar 19, 2016

why drop openssl completely, isn't it fixed in later php versions? rather compare php version? or do some feature test?

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Mar 19, 2016

why drop openssl completely

GrahamCampbell commented Mar 19, 2016

why drop openssl completely

@GrahamCampbell

This comment has been minimized.

Show comment
Hide comment
@GrahamCampbell

GrahamCampbell Mar 19, 2016

why drop openssl completely

This was reverted in 1.4.0.

GrahamCampbell commented Mar 19, 2016

why drop openssl completely

This was reverted in 1.4.0.

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Mar 19, 2016

Contributor

i understand it was reverted, but my question remains unanswered

Contributor

glensc commented Mar 19, 2016

i understand it was reverted, but my question remains unanswered

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott
Member

paragonie-scott commented Mar 19, 2016

@glensc See #96

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Mar 19, 2016

Contributor

so, the "not fork() safe" is stronger reason for completely drop instead of just version compare of fixed php versions?

Contributor

glensc commented Mar 19, 2016

so, the "not fork() safe" is stronger reason for completely drop instead of just version compare of fixed php versions?

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 19, 2016

Member

What fixed versions? This problem is unfixable on any PHP system that uses Apache.

Don't like it being "completely dropped"? Stick with 1.4. Otherwise, join us in 2.x land.

Member

paragonie-scott commented Mar 19, 2016

What fixed versions? This problem is unfixable on any PHP system that uses Apache.

Don't like it being "completely dropped"? Stick with 1.4. Otherwise, join us in 2.x land.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 19, 2016

Member

In case it wasn't obvious, we're maintaining both 1.x and 2.x branches.

2.x has the added benefit of being truer to random_bytes() which never hooks into OpenSSL's RNG.

1.x has greater compatibility.

Use which ever one you prefer.

Member

paragonie-scott commented Mar 19, 2016

In case it wasn't obvious, we're maintaining both 1.x and 2.x branches.

2.x has the added benefit of being truer to random_bytes() which never hooks into OpenSSL's RNG.

1.x has greater compatibility.

Use which ever one you prefer.

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Mar 19, 2016

Contributor

you keep saying "this problem", but no explanation what that "this problem" is. from #96 i read out "In most versions of PHP, it lies about being secure", but #70014 says it's fixed in 5.6.11, "uses MD5 as a CSPRNG", but from some comments i read out openssl can be compiled as SHA1 there instead.

Contributor

glensc commented Mar 19, 2016

you keep saying "this problem", but no explanation what that "this problem" is. from #96 i read out "In most versions of PHP, it lies about being secure", but #70014 says it's fixed in 5.6.11, "uses MD5 as a CSPRNG", but from some comments i read out openssl can be compiled as SHA1 there instead.

@paragonie-scott

This comment has been minimized.

Show comment
Hide comment
@paragonie-scott

paragonie-scott Mar 20, 2016

Member

This is the problem I'm referring to.

Is there any point to continue this discussion? Use 1.x if you want OpenSSL, use 2.x if you do not.

Member

paragonie-scott commented Mar 20, 2016

This is the problem I'm referring to.

Is there any point to continue this discussion? Use 1.x if you want OpenSSL, use 2.x if you do not.

@glensc

This comment has been minimized.

Show comment
Hide comment
@glensc

glensc Mar 21, 2016

Contributor

so this was the answer original question.

my question is not about what version to use (i do not use any version of this library), i'm trying to understand background of decisions in this library.

Contributor

glensc commented Mar 21, 2016

so this was the answer original question.

my question is not about what version to use (i do not use any version of this library), i'm trying to understand background of decisions in this library.

@AndrewCarterUK

This comment has been minimized.

Show comment
Hide comment
@AndrewCarterUK

AndrewCarterUK Apr 26, 2016

Contributor

@glensc - That is a separate security issue also affecting the OpenSSL random bytes function that was fixed in a later PHP version. The other security issue (regarding forking) is a "cant fix/wont fix" from OpenSSL and as a result this function looks to be always be insecure on all versions of PHP.

Edit - It actually looks like the PHP team is creating a patch for this: https://bugs.php.net/bug.php?id=71915

Contributor

AndrewCarterUK commented Apr 26, 2016

@glensc - That is a separate security issue also affecting the OpenSSL random bytes function that was fixed in a later PHP version. The other security issue (regarding forking) is a "cant fix/wont fix" from OpenSSL and as a result this function looks to be always be insecure on all versions of PHP.

Edit - It actually looks like the PHP team is creating a patch for this: https://bugs.php.net/bug.php?id=71915

@maltfield

This comment has been minimized.

Show comment
Hide comment
@maltfield

maltfield Aug 25, 2018

fyi, rather than allow php access to '/dev/urandom' (which I imagine would have some negative externalities), I just installed the php libsodium pecl extension.

I encountered this issue with phplist v3.3.3 on a CentOS 7 server running apache v2.4.6 with php v5.6.33.

Solution was to run:

yum install php-pecl-libsodium
httpd -t && service httpd restart

See this article for more info:

maltfield commented Aug 25, 2018

fyi, rather than allow php access to '/dev/urandom' (which I imagine would have some negative externalities), I just installed the php libsodium pecl extension.

I encountered this issue with phplist v3.3.3 on a CentOS 7 server running apache v2.4.6 with php v5.6.33.

Solution was to run:

yum install php-pecl-libsodium
httpd -t && service httpd restart

See this article for more info:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment