Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 1:39 PM, Bean bean12...@gmail.com wrote:
On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
But now it has a technical problem: it may read post array definitions.
If any of post-array memory is MMIO or absent reading from it may have
peculiar consequences
Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)
Hi,
Right, I think it'd be better to use fixed size array, perhaps we can
define a type grub_password_t for it.
BTW, with fixed size array, the following algorithm should run exactly
the same amount of instruction each time:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
int r1 = 0;
int r2 = 0;
int i, *p;
p = r1;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p |= (*s1 ^ *s2);
if (*s1 == '\0')
p = r2;
}
return (r1 != 0);
}
Hi,
Oh sorry, this one still have some issue, this should work:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
int r1 = 0;
int r2 = 0;
int i, *p1, *p2;
p1 = p2 = r1;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p1 |= (*s1 ^ *s2);
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
}
return (r1 != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 4:28 PM, Bean bean12...@gmail.com wrote:
On Tue, Nov 10, 2009 at 1:39 PM, Bean bean12...@gmail.com wrote:
On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
But now it has a technical problem: it may read post array definitions.
If any of post-array memory is MMIO or absent reading from it may have
peculiar consequences
Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)
Hi,
Right, I think it'd be better to use fixed size array, perhaps we can
define a type grub_password_t for it.
BTW, with fixed size array, the following algorithm should run exactly
the same amount of instruction each time:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
int r1 = 0;
int r2 = 0;
int i, *p;
p = r1;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p |= (*s1 ^ *s2);
if (*s1 == '\0')
p = r2;
}
return (r1 != 0);
}
Hi,
Oh sorry, this one still have some issue, this should work:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
int r1 = 0;
int r2 = 0;
int i, *p1, *p2;
p1 = p2 = r1;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p1 |= (*s1 ^ *s2);
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
}
return (r1 != 0);
}
Hi,
Just in case p2 is optimized out by gcc:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char r3 = 0;
char *p1, *p2;
int i;
p1 = r1;
p2 = r3;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p1 |= (*s1 ^ *s2);
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
(*p2)++;
}
return (r1 != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 4:46 PM, Bean bean12...@gmail.com wrote:
Hi,
Just in case p2 is optimized out by gcc:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char r3 = 0;
char *p1, *p2;
int i;
p1 = r1;
p2 = r3;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p1 |= (*s1 ^ *s2);
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
(*p2)++;
}
return (r1 != 0);
}
Hi,
Perhaps this one, it's more symmetrical:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char r3 = 0;
char *p1, *p2;
int i;
p1 = r1;
p2 = r3;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
char c;
c = (*s1 ^ *s2);
*p1 |= c;
*p2 |= c;
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
}
return (r1 != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 4:52 PM, Bean bean12...@gmail.com wrote:
Hi,
Perhaps this one, it's more symmetrical:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char r3 = 0;
char *p1, *p2;
int i;
p1 = r1;
p2 = r3;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
char c;
c = (*s1 ^ *s2);
*p1 |= c;
*p2 |= c;
if (*s1 == '\0')
p1 = r2;
else
p2 = r2;
}
return (r1 != 0);
}
Hi,
BTW, just in case there is delay in hardware when the same memory
address r2 is accessed repeatedly:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char r3 = 0;
char r4 = 0;
char *p1, *p2;
int i;
p1 = r1;
p2 = r3;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
char c;
c = (*s1 ^ *s2);
*p1 |= c;
*p2 |= c;
if (*s1 == '\0')
p1 = r2;
else
p2 = r4;
}
return (r1 != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
Well, it seems I lost something somewhere. I don't understand the need
of doing it exactly sizeof (grub_password_t) times, except from having a
perfectly symetric function. IMHO, stopping the comparison when the
input buffer is done reading, or when the maximum size of a passphrase
is reached does not leak any information to the attacker. So I would
stick to
typedef char grub_password_t[1024];
int
auth_strcmp (const grub_password_t input, grub_password_t key)
{
int retval, it;
for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++)
{
retval |= (*input != *key);
if (*input == '\0')
break;
}
return !retval;
}
Also, take care that it requires to check how the function is
optimized; sometimes you have surprises ... ;)
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr5d90ACgkQBV7eXqefhqio+QCfba54+l45DiQNyI3IzfnwgvVe
tbUAnRTPI+yYSZoVZLfM9fze7c7cvRQN
=EjYS
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 10:25 PM, Duboucher Thomas tho...@duboucher.eu wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
Well, it seems I lost something somewhere. I don't understand the need
of doing it exactly sizeof (grub_password_t) times, except from having a
perfectly symetric function. IMHO, stopping the comparison when the
input buffer is done reading, or when the maximum size of a passphrase
is reached does not leak any information to the attacker. So I would
stick to
typedef char grub_password_t[1024];
int
auth_strcmp (const grub_password_t input, grub_password_t key)
{
int retval, it;
for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++)
{
retval |= (*input != *key);
if (*input == '\0')
break;
}
return !retval;
}
Also, take care that it requires to check how the function is
optimized; sometimes you have surprises ... ;)
Hi,
My previous function ensures that execution time is the same
regardless of the input. Although it's not necessary, I guess it's a
nice feature to have. BTW, the simpler function does leak one
information, the size of buffer as the execution time would increase
until the buffer size is reached.
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 8:25 AM, Duboucher Thomas tho...@duboucher.eu wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
Well, it seems I lost something somewhere. I don't understand the need
of doing it exactly sizeof (grub_password_t) times, except from having a
perfectly symetric function. IMHO, stopping the comparison when the
input buffer is done reading, or when the maximum size of a passphrase
is reached does not leak any information to the attacker. So I would
stick to
typedef char grub_password_t[1024];
int
auth_strcmp (const grub_password_t input, grub_password_t key)
{
int retval, it;
for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++)
After changing the parameter type, those postincrements won't do what
you expect.
{
retval |= (*input != *key);
if (*input == '\0')
break;
}
return !retval;
}
Also, take care that it requires to check how the function is
optimized; sometimes you have surprises ... ;)
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr5d90ACgkQBV7eXqefhqio+QCfba54+l45DiQNyI3IzfnwgvVe
tbUAnRTPI+yYSZoVZLfM9fze7c7cvRQN
=EjYS
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 richardvo...@gmail.com a écrit : for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++) After changing the parameter type, those postincrements won't do what you expect. Damn examinations; I really need to sleep! =) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr5pRoACgkQBV7eXqefhqgzwwCgh9BMUl9V7kQ6M/YjscwDIVRP OVIAoJj+WMW+tZ58wLg03oCuvEuxj77n =6gXS -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bean a écrit : Hi, My previous function ensures that execution time is the same regardless of the input. Although it's not necessary, I guess it's a nice feature to have. BTW, the simpler function does leak one information, the size of buffer as the execution time would increase until the buffer size is reached. Hi, Yes, constant time of execution _is_ a constraint of this function. However, I don't think that giving access to the size of the buffer is a leak per se, the source code of Grub being available for everyone; We only need not to leak more informations than already available. Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr5pjgACgkQBV7eXqefhqhm8ACfVefuwV/IVdB2NzWrPeEzksfs jeIAn1xmJzNWwTa1gKdjvA/o4MQSLsLI =n0nc -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Duboucher Thomas wrote: Bean a écrit : Hi, My previous function ensures that execution time is the same regardless of the input. Although it's not necessary, I guess it's a nice feature to have. BTW, the simpler function does leak one information, the size of buffer as the execution time would increase until the buffer size is reached. Hi, Yes, constant time of execution _is_ a constraint of this function. However, I don't think that giving access to the size of the buffer is a leak per se, the source code of Grub being available for everyone; We only need not to leak more informations than already available. Yes. No security analysis can assume attacker doesn't have the source code Thomas. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Bean wrote:
On Tue, Nov 10, 2009 at 10:25 PM, Duboucher Thomas tho...@duboucher.eu
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
Oh, I just come up with a better way to do this:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
char r1 = 0;
char r2 = 0;
char *p;
int i, c;
p = r1;
c = 0;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p | = (*s1 ^ *s2);
if ((int) *s1 == c)
{
p = r2;
c = 0x100;
}
}
return (r1 != 0);
}
The condition (int) *s1 == c would be true exactly once.
Well, it seems I lost something somewhere. I don't understand the need
of doing it exactly sizeof (grub_password_t) times, except from having a
perfectly symetric function. IMHO, stopping the comparison when the
input buffer is done reading, or when the maximum size of a passphrase
is reached does not leak any information to the attacker. So I would
stick to
typedef char grub_password_t[1024];
With this change grub_auth_strcmp becomes a misnomer. I would prefer to
call it grub_auth_memcmp then. I'll also look into which other free
secure strcmp are available
int
auth_strcmp (const grub_password_t input, grub_password_t key)
{
int retval, it;
for (it = retval = 0; it PASSPHRASE_MAXSIZE; it++, input++, key++)
{
retval |= (*input != *key);
if (*input == '\0')
break;
}
return !retval;
}
Also, take care that it requires to check how the function is
optimized; sometimes you have surprises ... ;)
Hi,
My previous function ensures that execution time is the same
regardless of the input. Although it's not necessary, I guess it's a
nice feature to have. BTW, the simpler function does leak one
information, the size of buffer as the execution time would increase
until the buffer size is reached.
--
Regards
Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir 'phcoder' Serbinenko a écrit : With this change grub_auth_strcmp becomes a misnomer. I would prefer to call it grub_auth_memcmp then. I'll also look into which other free secure strcmp are available Asking developpers of projects such as GPG for advice could be a good idea. ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr52zcACgkQBV7eXqefhqhz0ACgkQV+VVBiriyzqRUyKhZTqLmN HaAAnR8HJqH2kpfqfQvGZsy7iKDhZlf5 =v1Qb -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan r...@aybabtu.com wrote: A security problem [1] was found in our password-checking routines, which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow. Additionally, I cherry-picked fixes for a few problems that should have made it to the release, like GNU/Hurd support (see NEWS file for details). The release branch is available in: sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/ If you have time, please test this tree, specially password support, to help find possible problems. Hi, Actually, the function of grub_auth_strcmp puzzles me, why would it need to wait 100 ms to return the result ? grub_auth_strcmp is used in many place, so the authorized could take some time to complete. And there is a hidden issue in it, grub_auth_strcmp can accept NULL pointer as input, but grub_strcmp doesn't check for NULL pointer. -- Bean My repository: https://launchpad.net/burg Document: https://help.ubuntu.com/community/Burg ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Bean wrote: On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan r...@aybabtu.com wrote: A security problem [1] was found in our password-checking routines, which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow. Additionally, I cherry-picked fixes for a few problems that should have made it to the release, like GNU/Hurd support (see NEWS file for details). The release branch is available in: sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/ If you have time, please test this tree, specially password support, to help find possible problems. Hi, Actually, the function of grub_auth_strcmp puzzles me, why would it need to wait 100 ms to return the result ? 10 ms actually. The goal is to take same amount of time indpendently of input values. But probably the delay should be around whole thing and it's how I'll do but for this urgent release this will do it grub_auth_strcmp is used in many place, so the authorized could take some time to complete. And there is a hidden issue in it, grub_auth_strcmp can accept NULL pointer as input, but grub_strcmp doesn't check for NULL pointer. Current codebase didn't use it -- Regards Vladimir 'phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Sun, Nov 08, 2009 at 06:08:39PM -0800, Jordan Uggla wrote: None of the .sh scripts ( autogen.sh and the scripts it uses ) are executable; I needed to chmod 744 *.sh before I could run ./autogen.sh successfully. After doing that make failed with an error in auth.c. This was with revision 1780. I've attached the output from ./configure and make. This was fixed in trunk, but release_1_97 didn't have it. I'll cherry-pick that one... -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 09, 2009 at 02:50:36PM +0100, Vladimir 'phcoder' Serbinenko wrote: Actually, the function of grub_auth_strcmp puzzles me, why would it need to wait 100 ms to return the result ? 10 ms actually. The goal is to take same amount of time indpendently of input values. But probably the delay should be around whole thing and it's how I'll do but for this urgent release this will do it Yes. I realized that too this morning, but it's not so important. The previous approach was tested and I'll release 1.97.1 with it, afterwards (or previously in trunk, thankfully we have branches now) we can fix it to do the right thing. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Bean wrote:
On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
Bean wrote:
On Mon, Nov 9, 2009 at 9:04 AM, Robert Millan r...@aybabtu.com wrote:
A security problem [1] was found in our password-checking routines,
which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow.
Additionally, I cherry-picked fixes for a few problems that should
have made it to the release, like GNU/Hurd support (see NEWS file
for details). The release branch is available in:
sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/
If you have time, please test this tree, specially password support,
to help find possible problems.
Hi,
Actually, the function of grub_auth_strcmp puzzles me, why would it
need to wait 100 ms to return the result ?
10 ms actually. The goal is to take same amount of time indpendently of
input values. But probably the delay should be around whole thing and
it's how I'll do but for this urgent release this will do it
Hi,
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int ret;
grub_uint64_t end;
end = grub_get_time_ms () + 100;
ret = grub_strcmp (s1, s2);
/* This prevents an attacker from deriving information about the
password from the time it took to execute this function. */
while (grub_get_time_ms () end);
return ret;
}
Isn't this 100 ms ? Anyway, the longest supported string is 1024 long,
I doubt there is any perceivable difference between them.
If attacker is on fast serial connection he could possibly measure the
difference
--
Regards
Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
Bean wrote:
On Mon, Nov 9, 2009 at 9:50 PM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
Hi,
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int ret;
grub_uint64_t end;
end = grub_get_time_ms () + 100;
ret = grub_strcmp (s1, s2);
/* This prevents an attacker from deriving information about the
password from the time it took to execute this function. */
while (grub_get_time_ms () end);
return ret;
}
Isn't this 100 ms ? Anyway, the longest supported string is 1024 long,
I doubt there is any perceivable difference between them.
If attacker is on fast serial connection he could possibly measure the
difference
Hi,
I'm not very confident in this piece of code. I would rather go with
something like
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int n;
volatile int ret = 0;
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
s1++; s2++;
}
return ret;
}
Ok, I typed this in a few minutes and I'm not confident either with
what I wrote; I would check that it works first. ;)
But the point here is that whatever the user gives as an input, it is
executed exactly n-th times, n being the length of the user input; and
that whatever the result of the 'if' statement is, the CPU realizes the
same amount of operations. By doing so, the attacker will only find out
how long it takes to make the comparison with a n caracters long input.
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr4VWgACgkQBV7eXqefhqhcIQCgpviYSvNqGqH3fi2Td4QChsam
JWQAni9R7zOWFMGBu5X9rXWOjenIXx31
=vnph
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote: Ok, I typed this in a few minutes and I'm not confident either with what I wrote; I would check that it works first. ;) But the point here is that whatever the user gives as an input, it is executed exactly n-th times, n being the length of the user input; and that whatever the result of the 'if' statement is, the CPU realizes the same amount of operations. By doing so, the attacker will only find out how long it takes to make the comparison with a n caracters long input. Actually, modern CPUs are very complex and the number of operations (or time taken by them) isn't easy to predict. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Robert Millan wrote:
On Mon, Nov 09, 2009 at 06:46:16PM +0100, Duboucher Thomas wrote:
Ok, I typed this in a few minutes and I'm not confident either with
what I wrote; I would check that it works first. ;)
But the point here is that whatever the user gives as an input, it is
executed exactly n-th times, n being the length of the user input; and
that whatever the result of the 'if' statement is, the CPU realizes the
same amount of operations. By doing so, the attacker will only find out
how long it takes to make the comparison with a n caracters long input.
Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
s1++; s2++;
}
It's pproximately how my first attempt worked and it had this bug. If
you can propose a good and tested code of this kind I would be ok with it
--
Regards
Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
Robert Millan wrote:
Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
Uhm I didn't check, but I'd suspect -Os would optimize this out.
Anyhow, if we move the fixed time wait to the outer loop, it should no
longer be a problem.
We could also check the approach taken by e.g. su from coreutils.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan r...@aybabtu.com wrote:
On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko wrote:
Robert Millan wrote:
Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
Uhm I didn't check, but I'd suspect -Os would optimize this out.
Anyhow, if we move the fixed time wait to the outer loop, it should no
longer be a problem.
We could also check the approach taken by e.g. su from coreutils.
Hi,
How about this one:
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);
return (result != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Bean wrote:
On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan r...@aybabtu.com wrote:
On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko
wrote:
Robert Millan wrote:
Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
Uhm I didn't check, but I'd suspect -Os would optimize this out.
Anyhow, if we move the fixed time wait to the outer loop, it should no
longer be a problem.
We could also check the approach taken by e.g. su from coreutils.
Hi,
How about this one:
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);
return (result != 0);
}
Welcome to club: try it with
abc, abcdef
They will match :(. Exactly the same problem as with my code but I like
the approach. Perhaps:
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);
return !(result == 0 *s2 == 0);
}
--
Regards
Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 2:46 AM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
Bean wrote:
On Tue, Nov 10, 2009 at 2:25 AM, Robert Millan r...@aybabtu.com wrote:
On Mon, Nov 09, 2009 at 07:15:48PM +0100, Vladimir 'phcoder' Serbinenko
wrote:
Robert Millan wrote:
Actually, modern CPUs are very complex and the number of operations (or
time taken by them) isn't easy to predict.
It's generally a good practice to do exactly same operations
independently of result just store the result in a separate variable
it's how RSA is correctly implemented
for (n = grub_strlen (s1); n = 0; n--)
{
if (*s1 != *s2)
ret |= 1;
else
ret |= 0;
Uhm I didn't check, but I'd suspect -Os would optimize this out.
Anyhow, if we move the fixed time wait to the outer loop, it should no
longer be a problem.
We could also check the approach taken by e.g. su from coreutils.
Hi,
How about this one:
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);
return (result != 0);
}
Welcome to club: try it with
abc, abcdef
They will match :(. Exactly the same problem as with my code but I like
the approach. Perhaps:
int
grub_auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
for (; *s1 != 0; s1++, s2++)
result += (*s1 != *s2);
return !(result == 0 *s2 == 0);
}
Hi,
This one work:
int
auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
while (1)
{
result += (*s1 != *s2);
if (*s1 == 0)
break;
s1++;
s2++;
}
return (result != 0);
}
The trick is to compare the ending '\0' as well, so that partial match
is not satisfied.
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bean a écrit :
Hi,
This one work:
int
auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
while (1)
{
result += (*s1 != *s2);
if (*s1 == 0)
break;
s1++;
s2++;
}
return (result != 0);
}
The trick is to compare the ending '\0' as well, so that partial match
is not satisfied.
Yep, I like this one, but I would prefer using an OR instead of an ADD
(with a highly hypothetical integer overflow :p) and because it's nicer
in terms of pure logic.
The comparison beetwen s1 and s2 is false if *s1 is different from
*s2, or recursively if the comparison beetwen s1+1 and s2+1 is false
int
auth_strcmp (const char *s1, const char *s2)
{
int ret = 0;
for (;;)
{
ret |= (*s1 != *s2);
if (*s1 == '\0')
break;
s1++;
s2++;
}
return ret;
}
Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr4he4ACgkQBV7eXqefhqj0kACgkgE60xJe5X/zpmXoPEd9SsT9
6H8An113fF03h0cndz2LpJvqnPyJ3EPx
=5MEi
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Duboucher Thomas wrote:
Bean a écrit :
Hi,
This one work:
int
auth_strcmp (const char *s1, const char *s2)
{
int result = 0;
while (1)
{
result += (*s1 != *s2);
if (*s1 == 0)
break;
s1++;
s2++;
}
return (result != 0);
}
The trick is to compare the ending '\0' as well, so that partial match
is not satisfied.
Yep, I like this one, but I would prefer using an OR instead of an ADD
(with a highly hypothetical integer overflow :p) and because it's nicer
in terms of pure logic.
The comparison beetwen s1 and s2 is false if *s1 is different from
*s2, or recursively if the comparison beetwen s1+1 and s2+1 is false
int
auth_strcmp (const char *s1, const char *s2)
{
int ret = 0;
for (;;)
{
ret |= (*s1 != *s2);
if (*s1 == '\0')
break;
s1++;
s2++;
}
return ret;
}
But now it has a technical problem: it may read post array definitions.
If any of post-array memory is MMIO or absent reading from it may have
peculiar consequences
Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)
Thomas.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote: Well, the only way to solve that problem would be IMHO to add a limit to the size of s2, and use this maximum size as an end condition for the 'for' statement. Any better idea? :) We have a maximum line read size anyway. If we do this, we might as well make that limit global so that the macro can be shared with this routine. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan a écrit : On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote: Well, the only way to solve that problem would be IMHO to add a limit to the size of s2, and use this maximum size as an end condition for the 'for' statement. Any better idea? :) We have a maximum line read size anyway. If we do this, we might as well make that limit global so that the macro can be shared with this routine. Sounds good to me. :) Any ideas for renaming s1 and s2? Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3 =okR/ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Duboucher Thomas wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Millan a écrit :
On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote:
Well, the only way to solve that problem would be IMHO to add a limit
to the size of s2, and use this maximum size as an end condition for the
'for' statement. Any better idea? :)
We have a maximum line read size anyway. If we do this, we might as
well make that limit global so that the macro can be shared with
this routine.
Sounds good to me. :)
Any ideas for renaming s1 and s2?
Thomas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t
cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3
=okR/
-END PGP SIGNATURE-
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Hello,
I'd be concerned about (s1 != s2). Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?. I'd be worried about all the ways (and future ways)
compilers might help us and introduce time differences.
I'd feel most comfortable with the time delay, but why not stick to
complete artithmetic?
int i;
int acc = 0;
for(i=0;iMAX_LEN;i++,s1++,s2++)
{
acc |= (*s1 ^ *s2);
if (*s1 == 0)
break;
}
return (acc == 0);
Also, these strcmp functions don't properly return or . Just = /
!=. However, my context being so new is quite limited.
Darron
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 9, 2009 at 4:46 PM, Duboucher Thomas tho...@duboucher.eu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan a écrit : On Mon, Nov 09, 2009 at 10:43:48PM +0100, Duboucher Thomas wrote: Well, the only way to solve that problem would be IMHO to add a limit to the size of s2, and use this maximum size as an end condition for the 'for' statement. Any better idea? :) We have a maximum line read size anyway. If we do this, we might as well make that limit global so that the macro can be shared with this routine. Sounds good to me. :) Any ideas for renaming s1 and s2? correct_key and attempted_key But there seems to still be potential for overflow on one of the strings. Are both strings in fixed-equal-length buffers? That should be clearly documented. Thomas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4m8EACgkQBV7eXqefhqj9SgCgjHomnoIkzzu5WuTCZQVcB/8t cwcAn1EkevCL3PXGlIuhLzFPlER9fXD3 =okR/ -END PGP SIGNATURE- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
Hello,
I'd be concerned about (s1 != s2). Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?. I'd be worried about all the ways (and future ways) compilers
might help us and introduce time differences.
I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there. Good find.
I'd feel most comfortable with the time delay, but why not stick to complete
artithmetic?
I agree. But I think you've inverted the return value (strcmp returns
0 on perfect match).
int i;
int acc = 0;
for(i=0;iMAX_LEN;i++,s1++,s2++)
{
acc |= (*s1 ^ *s2);
if (*s1 == 0)
break;
}
return (acc == 0);
Also, these strcmp functions don't properly return or . Just = / !=.
However, my context being so new is quite limited.
Darron
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
richardvo...@gmail.com wrote:
Hello,
I'd be concerned about (s1 != s2). Depending on how efficiently this
compiles, could not branch prediction make this faster for match vs. not
match, etc?. I'd be worried about all the ways (and future ways) compilers
might help us and introduce time differences.
I was avoiding suggesting new conditionals for that reason, but didn't
see the one already there. Good find.
I'd feel most comfortable with the time delay, but why not stick to complete
artithmetic?
I agree. But I think you've inverted the return value (strcmp returns
0 on perfect match).
Yeah, sorry. That'd be a slightly larger security hole, eh?
I meant to just show the acc |= (*s1 ^ *s2); line, but I decided to
throw the rest in for context and didn't really check it. I noticed
that just AFTER sending.
int i;
int acc = 0;
for(i=0;iMAX_LEN;i++,s1++,s2++)
{
acc |= (*s1 ^ *s2);
if (*s1 == 0)
break;
}
return (acc == 0);
Also, these strcmp functions don't properly return or . Just = / !=.
However, my context being so new is quite limited.
Darron
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Tue, Nov 10, 2009 at 5:34 AM, Vladimir 'phcoder' Serbinenko
phco...@gmail.com wrote:
But now it has a technical problem: it may read post array definitions.
If any of post-array memory is MMIO or absent reading from it may have
peculiar consequences
Also, because s1 and s2 have two differents roles, I think it would be
best to give them names that better suits them. ;)
Hi,
Right, I think it'd be better to use fixed size array, perhaps we can
define a type grub_password_t for it.
BTW, with fixed size array, the following algorithm should run exactly
the same amount of instruction each time:
typedef char grub_password_t[1024];
int
grub_auth_strcmp (const grub_password_t s1, const grub_password_t s2)
{
int r1 = 0;
int r2 = 0;
int i, *p;
p = r1;
for (i = 0; i sizeof (grub_password_t); i++, s1++, s2++)
{
*p |= (*s1 ^ *s2);
if (*s1 == '\0')
p = r2;
}
return (r1 != 0);
}
--
Bean
My repository: https://launchpad.net/burg
Document: https://help.ubuntu.com/community/Burg
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Imminent bugfix release (1.97.1)
A security problem [1] was found in our password-checking routines, which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow. Additionally, I cherry-picked fixes for a few problems that should have made it to the release, like GNU/Hurd support (see NEWS file for details). The release branch is available in: sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/ If you have time, please test this tree, specially password support, to help find possible problems. Thanks! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555195 -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
On Mon, Nov 09, 2009 at 02:04:22AM +0100, Robert Millan wrote: The release branch is available in: sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/ Or via http if you don't have a Savannah account: http://bzr.savannah.gnu.org/r/grub/branches/release_1_97/ -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Imminent bugfix release (1.97.1)
None of the .sh scripts ( autogen.sh and the scripts it uses ) are executable; I needed to chmod 744 *.sh before I could run ./autogen.sh successfully. After doing that make failed with an error in auth.c. This was with revision 1780. I've attached the output from ./configure and make. On Sun, Nov 8, 2009 at 5:04 PM, Robert Millan r...@aybabtu.com wrote: A security problem [1] was found in our password-checking routines, which affects GRUB 1.97. I'll be releasing 1.97.1 tomorrow. Additionally, I cherry-picked fixes for a few problems that should have made it to the release, like GNU/Hurd support (see NEWS file for details). The release branch is available in: sftp://bzr.savannah.gnu.org/srv/bzr/grub/branches/release_1_97/ If you have time, please test this tree, specially password support, to help find possible problems. Thanks! [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555195 -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for cmp... cmp checking for bison... bison checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for ruby... /usr/bin/ruby checking for makeinfo... /usr/bin/makeinfo checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking whether byte ordering is bigendian... no checking size of void *... 4 checking size of long... 4 checking whether our compiler is apple cc... no checking for help2man... /usr/bin/help2man checking for posix_memalign... yes checking for memalign... yes checking for asprintf... yes checking for objcopy... objcopy checking for strip... strip checking for nm... nm checking whether optimization for size works... yes checking whether -falign-loops works... yes checking whether -fno-dwarf2-cfi-asm works... yes checking whether our target compiler is apple cc... no checking for command to convert module to ELF format... checking whether `gcc' generates calls to `__enable_execute_stack()'... no checking whether `gcc' has `-fPIE' as default... no checking whether `gcc' accepts `-fstack-protector'... yes checking whether `gcc' accepts `-mstack-arg-probe'... yes checking for __bswapsi2... yes checking for __bswapdi2... yes checking for __ashldi3... yes checking for __ashrdi3... yes checking for __lshrdi3... yes checking for __trampoline_setup... no checking for __ucmpdi2... yes checking whether target compiler is working... yes checking whether objcopy works for absolute addresses... yes checking whether linker accepts --build-id=none... yes checking if C symbols get an underscore after compilation... no checking if __bss_start is defined by the compiler... yes checking if edata is defined by the compiler... yes checking if _edata is defined by the compiler... yes checking if end is defined by the compiler... yes checking if _end is defined by the compiler... yes checking whether addr32 must be in the same line as the instruction... yes checking for .code16 addr32 assembler support... yes checking whether an absolute indirect call/jump must not be prefixed with an asterisk... no checking whether options required for efiemu work... yes checking for wgetch in -lncurses... yes checking ncurses/curses.h usability... no checking ncurses/curses.h presence... no checking for ncurses/curses.h... no checking ncurses.h
