[Solved] Problem during trunk installation

[snoy_ms]

During "make install" the trunk from 08/10/2007 stops at the line
(/tmp/ispcp-1.0.0/var/www/ispcp/engine/messager/ispcp-db-keys.pl).

Quote:....
....
....
make[1]: Leaving directory `/web/svn/nightly/gui'
cd ./keys && make install
make[1]: Entering directory `/web/svn/nightly/keys'
perl rpl.pl /tmp/ispcp-1.0.0/var/www/ispcp/gui/include/ispcp-db-keys.php /tmp/ispcp-1.0.0/var/www/ispcp/engine/ispcp-db-keys.pl /tmp/ispcp-1.0.0/var/www/ispcp/engine/messager/ispcp-db-keys.pl

if i wait, nothing happens, and if i push strg-c i get this messages:

Quote:.....
.....
make[1]: *** wait: No child processes. Stop.
make[1]: *** Waiting for unfinished jobs....
make[1]: *** wait: No child processes. Stop.
make: *** wait: No child processes. Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes. Stop.

Anyone else this problem? I use a fresh minimal etch 4.0 system.
All deb's installed.

snoy_ms

[zpin]

seems to be a very common problem...

apply this patch to fix it:

Code:

Index: engine/ispcp_common_methods.pl
===================================================================
--- engine/ispcp_common_methods.pl      (revision 829)
+++ engine/ispcp_common_methods.pl      (working copy)
@@ -998,7 +998,7 @@

     }

-    my $rs = open(F, '<', '/dev/random');
+    my $rs = open(F, '<', '/dev/urandom');

     if (!defined($rs)) {

[raphael]

please don't double post. I've already replied to your other post: http://www.isp-control.net/forum/setup-h...-1480.html

zpin: please stop telling people to use such patch, since it reduces the effectiveness of ispCP's security (if we were to use urandom it'd be easier to use perl's pseudo random number generator instead)

[snoy_ms]

Ok, thx i test it.

The other post is about my hostname problem during "setup" with rc2 version, and this post here is about my problem during "make install" with a trunk version.

[snoy_ms]

I tested it, and nothing happens, same problem with the trunk version.
It stops at the same line... :-(

[zpin]

raphael Wrote:please don't double post. I've already replied to your other post: http://www.isp-control.net/forum/setup-h...-1480.html

zpin: please stop telling people to use such patch, since it reduces the effectiveness of ispCP's security (if we were to use urandom it'd be easier to use perl's pseudo random number generator instead)

Even though urandom (or the perl random generater) might be might be less random than /dev/random I consider it practically impossible for anyone to exploit this fact. It is more likely that an attacker accesses some software installation during setup when the admin has no yet set up a proper admin account and - by mistake - made the setup publicly accessible than that he can calculate the random number.
I for one was glad to finally have the make install complete. The different cat X > /dev/random somehow didn't work for me.

[RatS]

Cryptographies lives from randomness it's not pseudo, because pseudo can be calculated via a function. We can try to stress the CPU a bit to fill the Entrophie pool; however a restart should create enough interrupts to install ispCP.

[zpin]

Sure, but that wasn't the point. The urandom number is as good as impossible to predict it in practice and during the installation it's - afaik - only used for the pma blowfish secret. I'm not sure but I think urandom also uses the kernel entropy, but if it runs out it falls back to another mechanism.
So anyway, this is a frequent issue and something needs to be done about it.
My suggestions:
a) Use urandom (or perl rand) in "make install" and state the remotely existant security issue with pma cookies
b) Print a clearly visible notice before the last step in "make install" that informs the user about the possible delay and how to circumvent it.
c) Add a timeout to the /dev/random read and try to generate entropy if reached.

[snoy_ms]

I test it, everything fine. I hit some keys while generating the key. But it just takes to long.

[raphael]

Quote:The different cat X > /dev/random somehow didn't work for me

what about piping the output to /dev/urandom? (but still not modifying the read from /dev/random in ispcp_common_methods).

Quote:I'm not sure but I think urandom also uses the kernel entropy, but if it runs out it falls back to another mechanism.

It does, and that's exactly the vulnerable point: if you first empty (or at least reduce) the entropy pool, further reads from /dev/urandom will use a more predictable algorithm and thus lower the security level.

Quote:and during the installation it's - afaik - only used for the pma blowfish secret

gen_sys_rand_num is used at two steps: make and ispcp-setup.
keys/rpl.pl generate the pair keys used for encrypting the database password.
ispcp-setup: calls it to generate pma's blowfish key