Re: 9n216.13.107.82
Can I suggest to those who responded to these that kneejerk reactions aren't useful? And that, if you really don't understand the nature of these, there is quite a lot of information to be gained by looking at the raw source and using a search site (instead of jumping to the urls to see what they are)? FTR, we assume that someone was spoofing luciano's email address, either randomly or as an attack on his character. - Joel Rees I'm imagining I'm a novelist: http://joel-rees-economics.blogspot.com/2016/06/econ101-novel-toc.html
Re: streql - Constant-time string comparison
On Sat, Nov 1, 2014 at 4:49 PM, Riley Baird
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
On 31/10/14 09:43, Joel Rees wrote:
[...]
This is a good way of doing the string comparison. However, it would
seem that upstream isn't really interested in hiding the length of the
strings, and doing so would only provide minimal security benefits.
They're kind of right, I'm discovering.
Would you be willing to sponsor the upstream streql,
Not sure what you mean there.
or do you think
that this version should be packaged instead after being modified for
Python?
No. I'm still playing with the concepts (Current state of things
below.) and realizing several things.
Probably, the best solution for a constant-time compare is to
pre-zero-fill the buffers and do binary compares (memcmp()) on the
entire buffers. That means that these routines are a bit superfluous
anyway.
My current results:
---
/* Near-constant run time string/memory compare, with test frame.
** by Joel Rees,
** derived from work by Peter Scott, Riley Baird, et. al., see
** https://lists.debian.org/debian-security/2014/10/msg00060.html
** https://github.com/PeterScott/streql
**
** Use of those parts original with Joel Rees allowed specifically under
** the Apache License version 2.0:
** http://opensource.org/licenses/Apache-2.0 ,
** or the Academic Free License v. 2.1
** http://opensource.org/licenses/AFL-3.0 ,
** or the GPL v. 2.0, 3.0 or later:
** http://www.gnu.org/copyleft/gpl.html
**
** Permission granted in advance
** for the Python Software Foundation to license or re-license
** any source code copyrights and/or patent rights held in such parts
by Joel Rees
** as part of Python Software Foundation software distributions and
publications.
**
** No claims or licensing assertions made concerning those parts not
original with Joel Rees.
*/
#include string.h
#include stdio.h
#include stdlib.h
/* dbg */ static int gcount = 0;
// The core function: test two regions of memory for bytewise equality
with near constant time.
// If cmplength is less than min( xlen, ylen ), comparison is incomplete.
// Lengths should be signed to make conditionals more balanced.
// Maximum string length is greater than 2^30 for 32 bit ints.
// Impervious to embedded NUL characters.
static int equals_internal_constimebin(
const char *x, int xlen,
const char *y, int ylen,
int cmplength) {
int result = 0;
/* dbg */ gcount = 0;
while ( --cmplength = 0 ) {
char xtemp;
char ytemp;
/* Using unsigned lengths here would induce unbalanced conditionals:
** unsigned int xlen;
** if ( xlen 0 ) {
** xtemp = *x++;
** --xlen;
** }
** else {
** xtemp = 0;// much quicker than indexed load and counter decrement
** }
** While signed lengths might be a problem with 16 bit ints,
** you really aren't going to be comparing strings 2^31 bytes
with this function.
*/
xtemp = ( --xlen = 0 ) ? *x++ : 0;
ytemp = ( --ylen = 0 ) ? *y++ : 0;
/* dbg */++gcount;
result |= xtemp ^ ytemp;
/* dbg printf( %c(%d):%c(%d) =%d@%d\n, xtemp, xlen, ytemp, ylen,
result, gcount ); */
}
return (xlen == ylen) (result == 0);
}
#define MAX_PASSWORD_LENGTH32
/* Fails silently on passwords longer than MAX_PASSWORD_LENGTH bytes.
// Note that using strlen() on the parameters will still induce some
timing leaks.
// DO NOT use this macro in real code.
*/
#define Mequals_internal_password( guess, key )\
equals_internal_constimebin( \
guess, strlen( guess ), \
key, strlen( key ), MAX_PASSWORD_LENGTH )
#define DEFAULT_PASSPHRASE_LENGTH64
/* Constant to default length, then dependent on length of guess.
// See above on use of strlen().
*/
static int equals_internal_passphrase( const char *guess, const char *key ) {
int guesslen = strlen( guess );
int keylen = strlen( key );
int complen = ( guesslen DEFAULT_PASSPHRASE_LENGTH ) ? guesslen :
DEFAULT_PASSPHRASE_LENGTH;
return equals_internal_constimebin( guess, guesslen, key, keylen, complen );
}
// The core function: test two regions of memory for bytewise equality
with near constant time.
// If cmplength is less than length of x or y, comparison is incomplete.
// Lengths should be signed to make conditionals more balanced.
// Maximum string length is 2^31 for 32 bit ints.
// Sensitivity to NULs allows use without strlen().
static int equals_internal_constime(
const char *x,
const char *y,
int cmplength) {
int result = 0;
int xstopped = 0;
int ystopped = 0;
/* dbg */ gcount = 0;
while ( --cmplength = 0 ) {
char xtemp = xstopped ? 0 : *x++;
char ytemp = ystopped ? 0 : *y++;
/* dbg */++gcount;
result |= xtemp ^ ytemp;
if ( xtemp == '\0' ) xstopped = cmplength;
if ( ytemp == '\0' ) ystopped = cmplength;
/* dbg printf( %c:%c =%d@%d (stopped x:%d y:%d)\n, xtemp, ytemp,
result, gcount, xstopped, ystopped ); */
}
return (xstopped == ystopped
Re: streql - Constant-time string comparison
On Sun, Nov 2, 2014 at 12:39 AM, Leslie S Satenstein lsatenst...@yahoo.com wrote: Please explain from where or how you get xlen and ylen. Do you make a complete pass through the string looking for a NULL character? If you do, then you are going to check your string once for the length, and once for the matching. The original source: https://github.com/PeterScott/streql/blob/master/streql.c Note this line: if (!PyArg_ParseTuple(args, et#et#, utf8, x, xlen, utf8, y, ylen)) return NULL; Riley is under the impression that Python strings are counted, rather than NUL-terminated. Given the answers to http://stackoverflow.com/questions/237128/is-there-a-reason-python-strings-dont-have-a-string-length-method I'm pretty sure he's right. [...] -- Joel Rees -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imysc4az08imby9i77iis+j8qnxz+mo9ywbricrszr...@mail.gmail.com
Re: streql - Constant-time string comparison
On Sun, Nov 2, 2014 at 1:21 AM, Jack j...@jackpot.uk.net wrote: On 01/11/2014 16:07, Joel Rees wrote: Riley is under the impression that Python strings are counted, rather than NUL-terminated. Given the answers to http://stackoverflow.com/questions/237128/is-there-a-reason-python-strings-dont-have-a-string-length-method I'm pretty sure he's right. [...] Why is this thread being pursued in Debian Security? Because I don't feel like signing up on github just to talk about trying to improve a project intended to add secure string comparison methods to python, which project has someone requesting a sponsor in debian. This mailing list is for security announcements. Oh? Then explain these: https://lists.debian.org/debian-security/2014/09/threads.html All Debian users are encouraged to subscribe, so that they know about the latest threats and updates. Perhaps you're thinking about this list: https://lists.debian.org/debian-security-announce/2014/threads.html It is not reasonable to use this list as a forum for discussing a Python string-comparison routine. If we weren't talking about security related issues in Python string handling, you'd be right. Can you please take your discussion somewhere else? Well, I'm not a dev, so I guess I don't belong here. I've said enough, I'm sure that if someone decides to sponsor the project they can work out the remaining details. Except for one more thing, I guess. That will be my last post here. -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iN4cowP8RN9+B2Fjhd8vab0i78f5kw9rq=nmk5yyam...@mail.gmail.com
Re: streql - Constant-time string comparison
On Sat, Nov 1, 2014 at 9:56 PM, Joel Rees joel.r...@gmail.com wrote: [...] Probably, the best solution for a constant-time compare is to pre-zero-fill the buffers and do binary compares (memcmp()) on the entire buffers. That means that these routines are a bit superfluous anyway. I was distracted when I wrote that. Constant width buffers, yes. memcmp(), of course not. -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOF4EgyZV-BT_oNPPxAo20tV73dqnSddB6=3c2w+4l...@mail.gmail.com
Re: streql - Constant-time string comparison
2014/10/30 16:52 Nicolas Rachinsky deb-securit...@ml.turing-complete.org
:
* Joel Rees joel.r...@gmail.com [2014-10-30 08:38 +0900]:
-
// The core function: test two regions of memory for bytewise equality
with constant time.
// If cmplength is less than min( xlen, ylen ), comparison is
incomplete.
static int equals_internal_constime(
const char *x, unsigned int xlen,
const char *y, unsigned int ylen,
int cmplength) {
int result = 0;
while ( --cmplength = 0 ) {
char xtemp = 0;
char ytemp = 0;
if ( --xlen = 0 ) xtemp = *x++;
if ( --ylen = 0 ) ytemp = *y++;
result |= xtemp ^ ytemp;
}
return (xlen == ylen) (result == 0);
}
-
Perhaps I am missing the obvious, but 0-1 ist UINT_MAX, which is
bigger than zero.
How embarrassing. One test would have caught that. Okay, use postdec mode
and greater than instead of greater than or equal. Or something similar.
And I should code instead of theorize.
And if this would work, the runtime of the loop's body would depend on
whether the assignments are executed or not.
It's the difference between having an indexed load or not. I think we can
assume the strings will be in cache after the first access.
Okay, don't initialize the local copy variables, use a two-way branch. And
you'll still have some slop because clearing a variable is quicker than
loading indexed.
Anyway, it's better than just dropping out of the loop.
(I have to get some way to write useful code on this lousy tablet.)
I'll be on the train for about an hour. You're welcome to fix the code
while I'm off-line.
--
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
Re: streql - Constant-time string comparison
Here's the result of my work to this point:
---
/* Near-constant run time string/memory compare, with test frame.
** by Joel Rees,
** derived from work by Peter Scott, Riley Baird, et. al., see
** https://lists.debian.org/debian-security/2014/10/msg00060.html
** https://github.com/PeterScott/streql
**
** Use allowed under GPL v. 3, see
** http://www.gnu.org/copyleft/gpl.html
*/
#include string.h
#include stdio.h
#include stdlib.h
/* dbg */ static int gcount = 0;
// The core function: test two regions of memory for bytewise equality
with constant time.
// If cmplength is less than min( xlen, ylen ), comparison is incomplete.
// Lengths should be signed to make conditionals more balanced.
static int equals_internal_constime(
const char *x, int xlen,
const char *y, int ylen,
int cmplength) {
int result = 0;
while ( --cmplength = 0 ) {
char xtemp;
char ytemp;
/* Using unsigned lengths here would induce unbalanced conditionals:
** unsigned int xlen;
** if ( xlen 0 ) {
** xtemp = *x++;
** --xlen;
** }
** else {
** xtemp = 0;
** }
** While this might be a problem with 16 bit ints,
** you really aren't going to be comparing strings 2^31 bytes
with this function.
*/
xtemp = ( --xlen = 0 ) ? *x++ : 0;
ytemp = ( --ylen = 0 ) ? *y++ : 0;
/* dbg */++gcount;
result |= xtemp ^ ytemp;
/* dbg printf( %c(%d):%c(%d) =%d@%d\n, xtemp, xlen, ytemp, ylen,
result, gcount ); */
}
return (xlen == ylen) (result == 0);
}
int main( int argc, char * argv[] ) {
char * left, * right;
int max = 32;
int result = 0;
if ( argc 2 ) {
left = argv[ 1 ];
right = argv[ 2 ];
if ( argc 3 ) max = strtol( argv[ 3 ], NULL, 0 );
gcount = 0;
result = equals_internal_constime( left, strlen( left ), right,
strlen( right ), max );
printf( result: %d, strcmp: %d, count: %d\n, result, strcmp(
left, right ), gcount );
if ( result != ( strcmp( left, right ) == 0 ) ) {
fputs( *** failed ***\n, stdout );
}
}
return EXIT_SUCCESS;
}
---
Note the change to signed lengths and the reasoning.
--
Joel Rees
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iNAJu-tMpvJ3nh4HTPJK=dy1td0gp-cyzza9de49fe...@mail.gmail.com
Re: streql - Constant-time string comparison
I gotta quit coding when I should be asleep.
On Fri, Oct 31, 2014 at 12:38 AM, Joel Rees joel.r...@gmail.com wrote:
Here's the result of my work to this point:
---
/* Near-constant run time string/memory compare, with test frame.
** by Joel Rees,
** derived from work by Peter Scott, Riley Baird, et. al., see
** https://lists.debian.org/debian-security/2014/10/msg00060.html
** https://github.com/PeterScott/streql
**
** Use allowed under GPL v. 3, see
** http://www.gnu.org/copyleft/gpl.html
Correct that to:
** Use of those parts original with Joel Rees allowed specifically under
** the Apache License version 2.0:
** http://opensource.org/licenses/Apache-2.0 ,
** or the Academic Free License v. 2.1
** http://opensource.org/licenses/AFL-3.0 ,
** or the GPL v. 2.0, 3.0 or later:
** http://www.gnu.org/copyleft/gpl.html
**
** Permission granted in advance
** for the Python Software Foundation to license or re-license
** any source code copyrights and/or patent rights held in such parts
by Joel Rees
** as part of Python Software Foundation publications and distributions.
**
** No claims or licensing assertions made concerning those parts not
original with Joel Rees.
*/
#include string.h
#include stdio.h
#include stdlib.h
/* dbg */ static int gcount = 0;
// The core function: test two regions of memory for bytewise equality
with constant time.
// If cmplength is less than min( xlen, ylen ), comparison is incomplete.
// Lengths should be signed to make conditionals more balanced.
static int equals_internal_constime(
const char *x, int xlen,
const char *y, int ylen,
int cmplength) {
int result = 0;
while ( --cmplength = 0 ) {
char xtemp;
char ytemp;
/* Using unsigned lengths here would induce unbalanced conditionals:
** unsigned int xlen;
** if ( xlen 0 ) {
** xtemp = *x++;
** --xlen;
** }
** else {
** xtemp = 0;
** }
** While this might be a problem with 16 bit ints,
** you really aren't going to be comparing strings 2^31 bytes
with this function.
*/
xtemp = ( --xlen = 0 ) ? *x++ : 0;
ytemp = ( --ylen = 0 ) ? *y++ : 0;
/* dbg */++gcount;
result |= xtemp ^ ytemp;
/* dbg printf( %c(%d):%c(%d) =%d@%d\n, xtemp, xlen, ytemp, ylen,
result, gcount ); */
}
return (xlen == ylen) (result == 0);
}
int main( int argc, char * argv[] ) {
char * left, * right;
int max = 32;
int result = 0;
if ( argc 2 ) {
left = argv[ 1 ];
right = argv[ 2 ];
if ( argc 3 ) max = strtol( argv[ 3 ], NULL, 0 );
gcount = 0;
result = equals_internal_constime( left, strlen( left ), right,
strlen( right ), max );
printf( result: %d, strcmp: %d, count: %d\n, result, strcmp(
left, right ), gcount );
if ( result != ( strcmp( left, right ) == 0 ) ) {
fputs( *** failed ***\n, stdout );
}
}
return EXIT_SUCCESS;
}
---
Note the change to signed lengths and the reasoning.
--
Joel Rees
--
Joel Rees
Somebody should take the Berne Convention out behind the barn and burn
it with the other trash.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/caar43ipovow_uzwv2gpgtjqfgridax5kxnyjnfdqvp+4sqt...@mail.gmail.com
Re: streql - Constant-time string comparison
2014/10/29 4:59 Riley Baird
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch:
On 29/10/14 00:20, Joel Rees wrote:
On Tue, Oct 28, 2014 at 12:08 PM, Riley Baird
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
Dear debian-security,
I am looking for a sponsor for my package streql.
In Python, the code for testing the equality of strings is susceptible
to a timing side channel attack. The package 'streql' provides a
function for comparing strings of equal length in equal time,
regardless
of the content of the strings.
* Package name: streql
Version : 3.0.2-1
Upstream Author : Peter Scott pe...@cueup.com
* URL :https://github.com/PeterScott/streql
* License : Apache 2.0
Section : python
It builds those binary packages:
python-streql - Constant-time string comparison (Python 2)
python3-streql - Constant-time string comparison (Python 3)
pypy-streql - Constant-time string comparison (PyPy)
To access further information about this package, please visit the
following
URL:
http://mentors.debian.net/package/streql
Alternatively, one can download the package with dget using this
command:
dget -x
http://mentors.debian.net/debian/pool/main/s/streql/streql_3.0.2-1.dsc
Changes since last upload:
* Initial release (Closes: #764443)
Regards,
Riley Baird
Let me try this suggestion again:
---
// The core function: test two regions of memory for bytewise equality.
static int equals_internal(const char *x, unsigned int xlen, const
char *y, unsigned int ylen) {
int minlen = ( xlen ylen ) ? ylen : xlen;
int i, result = 0;
for (i = 0; i minlen; i++) result |= x[i] ^ y[i];
return ( xlen == ylen ) ( result == 0 );
---
I haven't tested it, but I think the corner case I'm thinking about is
fairly clear.
As far as I can tell, your code ensures that even if the strings are of
different length, an equality calculation should be performed anyway,
however returning 0, on the grounds that this would make it more
difficult for an attacker to know that the two strings entered were of
different lengths. Is this right?
Yeah.
It still leaks length information, but not as obviously.
You could add a busy loop to push the leak to the other side of the sweep.
You could even play games with the busy loop to randomly extend it beyond
the place it would naturally terminate, just to reduce the incentive to
look. (Making sure your pseudo-random selection code is not data dependent,
of course.)
You could change the semantics of the API to allow making the execution
time depend on the length of attacker's guess.
Of course, it's not really hard to get true constant compare times, and
that's what I think I'd aim at.
--
Joel Rees
Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.
Re: streql - Constant-time string comparison
On Thu, Oct 30, 2014 at 4:58 AM, Riley Baird
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
On 29/10/14 19:55, Richard van den Berg wrote:
On 28-10-14 20:59 , Riley Baird wrote:
As far as I can tell, your code ensures that even if the strings are of
different length, an equality calculation should be performed anyway,
however returning 0, on the grounds that this would make it more
difficult for an attacker to know that the two strings entered were of
different lengths. Is this right?
Pardon my ignorance, but how much more difficult does it actually become
to determine the two inputs are of different length? In the original the
function returns right away if xlen != ylen. If the attacker can control
one of the inputs (say x), the change proposed by Joel will cause the
time of the compare to increment when xlen in increased until xlen ==
ylen. If this can be observed with enough precision the same objective
can be achieved.
Good point. Perhaps this could be fixed by,
origleny=len(y)
while len(x) = len(y):
y += '0'
result = i = 0
for i in xrange(len(x)):
result |= ord(x[i]) ^ ord(y[i])
return result == 0 and len(y) == origleny
This way, the time taken to complete the function will increase even
after xlen = ylen
However, with this I'm concerned that the 'while' loop will take up too
much time, thus still allowing an attacker to see when the string
lengths become equal. Is there a quicker way to append zeros to a string
such that it is equal in length to the other string?
Well, allocation of a string would tend to make the run time somewhat
arbitrary, but whether it would mask the length or not is kind of hard
to predict. Considering that the attack uses statistics, it's not hard
to look for double peaks.
I had a sort of similar idea, using a pair of local buffers, cycling
the string through the buffers, and got workable code. But I realized
I was just working too hard. A one byte buffer is plenty, and
simplifies the loop. Seriously simplifies the loop. (I think. Still
haven't really tested it or looked for corner cases.)
I'm going to spend some time testing the following today and tomorrow:
-
// The core function: test two regions of memory for bytewise equality
with constant time.
// If cmplength is less than min( xlen, ylen ), comparison is incomplete.
static int equals_internal_constime(
const char *x, unsigned int xlen,
const char *y, unsigned int ylen,
int cmplength) {
int result = 0;
while ( --cmplength = 0 ) {
char xtemp = 0;
char ytemp = 0;
if ( --xlen = 0 ) xtemp = *x++;
if ( --ylen = 0 ) ytemp = *y++;
result |= xtemp ^ ytemp;
}
return (xlen == ylen) (result == 0);
}
-
Picking the minimum length for cmplength when you call it would be the
same as I posted before. Picking the maximum length would bias the
execution time to the longer of the pair. Either way, sequencing
through lengths of guesses would (using statistical methods) reveal a
point where the time goes from constant to variable, as Richard notes
above.
If you can set an absolute max cmplength, you can always call it with
the absolute max and get strictly constant time compares. (Or maybe
use a manifest constant for cmplength.) For instance, for an API
dedicated to passwords, if you know that all passwords are 31 bytes
or less, you can pass 31 for cmplength on the call.
But when the same API could be used for passwords or 2048 bit keys,
you'd need to pass 256 for cmplength, which might be too long a wait
for some things. That's why I suggested the possibility of needing to
change the API.
Another possibility is to use the greater of xlen, ylen, and cmplength
in this function, which would avoid the problem of incomplete compares
I put in the comments, and would allow one to set a length, beyond
which we would not care if the length leaked. (20 or 32 might be
reasonable.) This could be done without changing the API from the
Python side.
A third possibility might be to offer an API where we call the x
parameter guess and the y parameter actual_key, and always set the
cmplength parameter to the guess length. That way, the time would
always be dependent on the attacker's guess (assuming the caller
function treated the parameters correctly).
Completely separate topic, but with just a little more effort and care
in the conditional paths, that could even be made an ordered compare,
by noting the difference of the first pair of bytes that differ.
--
Joel Rees
Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iN+tV3L=xqsp_ukan+kc4ywrj8-mf_sfktukzeh4-5...@mail.gmail.com
Re: streql - Constant-time string comparison
On Tue, Oct 28, 2014 at 12:08 PM, Riley Baird bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote: Dear debian-security, I am looking for a sponsor for my package streql. In Python, the code for testing the equality of strings is susceptible to a timing side channel attack. The package 'streql' provides a function for comparing strings of equal length in equal time, regardless of the content of the strings. * Package name: streql Version : 3.0.2-1 Upstream Author : Peter Scott pe...@cueup.com * URL : https://github.com/PeterScott/streql * License : Apache 2.0 Section : python It builds those binary packages: python-streql - Constant-time string comparison (Python 2) python3-streql - Constant-time string comparison (Python 3) pypy-streql - Constant-time string comparison (PyPy) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/streql Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/streql/streql_3.0.2-1.dsc Changes since last upload: * Initial release (Closes: #764443) Regards, Riley Baird I have a suggestion which I Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iN0iYPYOVSebhUJ9d4b7fNOVPaFSycKqQgORk=bu7c...@mail.gmail.com
Re: streql - Constant-time string comparison
On Tue, Oct 28, 2014 at 12:08 PM, Riley Baird
bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch wrote:
Dear debian-security,
I am looking for a sponsor for my package streql.
In Python, the code for testing the equality of strings is susceptible
to a timing side channel attack. The package 'streql' provides a
function for comparing strings of equal length in equal time, regardless
of the content of the strings.
* Package name: streql
Version : 3.0.2-1
Upstream Author : Peter Scott pe...@cueup.com
* URL : https://github.com/PeterScott/streql
* License : Apache 2.0
Section : python
It builds those binary packages:
python-streql - Constant-time string comparison (Python 2)
python3-streql - Constant-time string comparison (Python 3)
pypy-streql - Constant-time string comparison (PyPy)
To access further information about this package, please visit the following
URL:
http://mentors.debian.net/package/streql
Alternatively, one can download the package with dget using this command:
dget -x
http://mentors.debian.net/debian/pool/main/s/streql/streql_3.0.2-1.dsc
Changes since last upload:
* Initial release (Closes: #764443)
Regards,
Riley Baird
Let me try this suggestion again:
---
// The core function: test two regions of memory for bytewise equality.
static int equals_internal(const char *x, unsigned int xlen, const
char *y, unsigned int ylen) {
int minlen = ( xlen ylen ) ? ylen : xlen;
int i, result = 0;
for (i = 0; i minlen; i++) result |= x[i] ^ y[i];
return ( xlen == ylen ) ( result == 0 );
---
I haven't tested it, but I think the corner case I'm thinking about is
fairly clear.
--
Joel Rees
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CAAr43iMStL_-8iyGCre5fr76b7WH5Y12n=eaxlk4yqhzhl9...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
A little context? On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner h...@at.or.at wrote: [...] * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive What happens when you put your live-image CD or USB in a box whose boot ROM or BIOS ROM has been overwritten through some vulnerability and now contains a hook to a backdoor? I'm not going to say that the whole idea of a live-image system is full of holes, but I personally do not trust anything important to any of the live images I use from time to time on hardware I don't control, except for the live CDs I use for repairing systems that have gone belly-up. I have, in the past, brought live USBs home from work and booted them on my home hardware. I don't do that any more. (I'd have to mount the USB on a running system at home and verify the parts of the file system that shouldn't change.) * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are 2 weeks Yes it can. * updating the apt cache/lib is painful on an offline machine Don't turn your nose up at wrappers. Lots of very useful stuff around that is just wrapping something else. Quite stable, if the wrapper does its job fully. * an offline machine's threat model is drastically simpler I disagree with that, as you see. On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). I suggest looking at the reasons for that again. And any decent attacker with physical access to the machine will always get in. Isn't this a red herring? Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc I understand the hesitation. Having individual packages signed is a good lead to a false sense of security. One point I strongly suggest considering is, for example, that firefox, direct from mozilla.org, on stock debian, is more likely to have vulnerabilities than firefox (iceweasel) loaded from the debian packages archives. -- Joel Rees Computer memory is just fancy paper. The CPU and IO devices are just fancy pens. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43im5bnalp1fny9j63cqezizpf0uxgm-txufasc-lj6m...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 1:28 PM, Noah Meyerhans no...@debian.org wrote: On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote: MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. The point that you miss is that a chosen plaintext attack is not dependent on the secret key in use. If I stand on my head does that make more sense? Nope. Doesn't. It's an attack against the algorithm itself. Looking at it sideways doesn't help, either. If we sign publically available data (be it Debian packages, CD images, or this email) with a given key, we really aren't giving our adversaries anything that they can't create for themselves. Sure we are. We are providing them instances of a different experiment set than any they are likely do generate themselves. Unless we use keys generated by some algorithm they might use to generate data. And we are also giving them the use of our servers. Keys are cheap to generate. Keys that are cheap to generate should not be used on live data. If an adversary wants to perform chosen plaintext analysis, they can do so today with their own keys and with all the common public datasets they want. And generating/managing their own data is a time cost. Moreover, if they fail to use some arbitrary algorithm, their choice of key is hit-and-miss, mostly miss. But if they use some algorithm, they are subject to the problems of brute-forcing against a large attack domain. Getting all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images won't change anything. So, when you want to do a survey of most popular TV shows, you just generate your own survey results and don't bother to define and canvas an audience? You do understand that the most effective attacks against the algorithms are statistical in nature? (Not to mention that it shows a fundamental misunderstanding of what a digest algorithm like md5 actually is.) You like to work backwards, trying to generate data from a hash, I suppose? noah -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iobz5utdg2zdaglm6yszkhnjeo+1fw-whjzpp5smj2...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 5:04 AM, Jann Horn j...@thejh.net wrote: On Mon, Jul 07, 2014 at 08:09:14PM +0900, Joel Rees wrote: But again, that's only half the story. When you send a kernel image encrypted, they have the plaintext and the crypt, and the thing is large and hard. This is the kind of data that can be used to completely break an entire encryption algorithm. When you say break an entire encryption algorithm, do you mean find the key or really break the whole algorithm? Both, of course. If you mean break the whole algorithm and gain the ability to convert ciphertexts to plaintexts no matter what key was used, please consider that they could just encrypt a lot of data with random keys themselves instead of collecting it from the internet. If you mean find the key: So what? You're talking about session keys used in the TLS connection, right? Even if there was the kind of attack you're thinking about, it would only allow an attacker to gain access to the connection that he would be able to MITM anyway without the TLS layer. What are the encryption methods that underlie the current implementations of TLS? What were the previous methods? Why did they have to be changed? What did the research that induced the change use in getting the results they got? Have the researchers given up? No? What kinds of data do they use? Note that we still don't have a publicly known general attack against MD5 encryption for arbitrary plaintexts. MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. I'm not talking about suddenly facing the end of the world as we know it tomorrow. I'm talking about choosing to push the time when we have to shift encryption methods again a few years forward by casually providing more data for research. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iN=fguxegEdr16jr37tuE8osHDDPRdHZicDfZU=dyp...@mail.gmail.com
could we maybe serve checksums TLS on some mirrors? (was Re: concrete steps for improving apt downloading security and privacy)
On Thu, Jul 10, 2014 at 9:29 AM, Kitty Cat realizar.la@gmail.com wrote: For years I have been concerned with MITM attacks on Debian mirrors. [...] Hate to trivialize your concerns, but the Debian organization cannot control the mirrors people provide it and remain Debian. You have to remember that when even proposing problems, much less solutions. However, what if http://cdimage.debian.org/ is actually an NSA mirror site and not the real one? [...] When I download a new install image, I pretty much always go to random mirrors, some largish/mainish and some smalish/obscure and download the copies of the checksum files. If all the checksum files compare, I can be pretty confident that one of the following conditions exists: (1) The image is good if the checksum command reports the correct checksum. (2) Some attacker has compromised every mirror I have accessed. (3) Some attacker is doing deep inspections on my traffic and redirecting traffic every time I go looking for a debian mirror. I check a minimum of three mirrors, but when I'm feeling especially paranoid I'll check five or six. It occurs to me that I might cede some usefulness to having the checksums (not images) served TLS transport on at least one of the mirrors, if and only if I remember to set the SSL_CERT_FILE before I fire up lynx to go get the checksums. It won't help me if my randomness in choosing the servers isn't good enough in case (2), but it should help in case (3). -- Joel Rees Computer storage is just fancy paper, and the CPU and I/O are just a fancy pens -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iM+6AYc1owhZty+kR55VaXkOP8zd=y7u4vntv0ceco...@mail.gmail.com
the calculus of encrypting non-textual data (was Re: concrete steps for improving apt downloading security and privacy)
On Tue, Jul 8, 2014 at 5:13 AM, Andrea Zwirner and...@linkspirit.org wrote: On 07/07/2014 13:09, Joel Rees wrote: Sorry Joel, I almost totally disagree with your vision on privacy and security, but I really i don't want to go into the merit of it, because I think Lou is representing my vision already; I only have a question: Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter? Can you proof it? Memory of coursework in encryption. The professor did some simple encryption on uncompressed images and showed how the results tended not to hide the things one would want hidden. Then he pointed out that the parts of an image with the most information are the parts that are least likely to compress. And he pointed out that standard encryption methods tend to be byte-oriented, for speed. He did not require us to do any homework on it, so I don't have any special tools in my notebooks. 30 years ago. Heh. The technology has changed somewhat since then, but I recently read about some standard encrypted sound files that were playable, noisy, but recognizable. Same principle. Or maybe, you can tell the list what the attached image - that is encrypted with Moritz Muehlenhoff's and Florian Weimer's public keys - represent? You'll note that I never said it could be done on every encrypted image. I assume that, now the math has been pointed out to you, you won't mind if I decline the challenge? Cheers (and thanks Mr. Moritz and Mr. Florian - who were the only I had in my keyring - to accept being the judges of the challenge). :-) Give them my regards, and I hope they are not disappointed. I've got other things to do. Andrea Zwirner Sent from my Sylpheed -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43im8zdukxqmnej8_oqcjhreto0p_qtdhyiq5wilpzye...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
2014/07/07 11:32 Lou RUPPERT hims...@louruppert.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. Not true. If I'm looking at an https-enabled page, and elements included in the page are http-only, I want to know about it. Why? By the time you're looking at it, there's nothing to do about what has been sent in the clear. It means the site maintainer messed up, and potentially sensitive information is going in the clear despite being included from a web page that is https. https is not a flag for TOP SECRET NSA PLAN FOR BACKDOORING THE UNIVERSE'S COMPUTERS OHS NOES! It means a breach is potentially occurring and that I should stop what I'm doing if the information presented is sensitive. Most of what is sent https is not even classified sensitive. If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? I suppose, if I'm looking for shoes for my wife's birthday, and it's supposed to be a surprise, and she regularly analyzes the house's router logs to check whether the kids are going to pornofthemonth.xxx, ..., but that's not the wireless router, come to think of it. Does your wife check your router logs? Okay, I suppose my son might, but, seriously. Oh, I suppose, if I were the kind of person to go to porn sites, I might decide not to return to such a site that sent me it's bd pics plaintext. (Did you know that encrypting a picture sometimes results in a picture that looks like it has been through a random color-permuting filter?) Of course, if someone is tapping my stream and looking at the images I'm looking at, they probably also know what sites I'm connecting to. What I don't want is a site that claims to be 'secure' while leaking. Every site leaks. Secure pages that are blanket-sent TLS for the wrong reasons will not be analyzed for leaks, because the people who design the sight are unaware that TLS is not a big enough blanket. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Huh? Content creators and site managers probably want a tool that will highlight or red-circle elements on a page that are declared plaintext, and (as a different option or command) elements that will end up plaintext when the page is sent TLS. And they want the tool to walk their site automatically, leaving a log behind. Users want their browser to tell them when parts of the data in the query they send TLS are going to be sent plaintext. Some may want to know which elements are going to be sent plaintext. Some may want to scan for plaintext elements before they start filling in the form, so they don't waste their time. But they don't really care if the picture of the shoe or its title is being received plaintext. Such information is perceived as noise, unless they really are concerned about the off chance that someone might be capturing their data stream to find out what pictures or political rants they are accessing. Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. We're talking about datasets used to factor keys, right? Surely you see that is not all that we are talking about? If they want to perfect some secret squirrel factoring technique, there are plenty of popular candidates to use. So, give them more data. Give them more of the hard data, in fact. We don't need to worry about debian repos becoming the key that allows them to develop that technique. Really? I mean, the current encryptions will be broken sooner or later. You're voting for sooner? I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. Yes, but except for freebsd's(?) mistake of using it exclusively, you'll find that OSes mix the entropy sources when providing /dev/random
Re: concrete steps for improving apt downloading security and privacy
On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iOTxVcCGyh5+d4VA43279Np6cKm9=4sq-wl0a1v8j5...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT hims...@louruppert.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Joel Rees: On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner h...@at.or.at wrote: [rhetoric encouraging the use of TLS transport for mirrors] [list of current https mirrors] Far be it from me to argue with ucalgary.ca, but one thing that bothers me about using TLS as a download transport is that, if I were the spooks, and I wanted a huge sample of crypts from a known plaintext, I could think of worse ways to go than to get the opensource crowd to provide them for me. Any popular site with relatively static content would do that. And you know, the funny thing is that MSIE took to warning people when there was a mix of encrypted and unencrypted data on a page. How long ago? Yeah, I know, it was so they could display that red herring of a lock for secured pages. You don't need a warning when you are looking at un-encrypted data. You only need a warning if you are _sending_ un-encrypted data. See how Microsoft has been complicit in this particular social engineering scheme from a long time ago? (I thought, back then, that they were just being lazy or trying to meet a stupid market window with incomplete tech again. Naive of me, yes.) Apple store or Play store would probably provide a more useful dataset for them anyway. But not so interesting, and not so constant. Sure, enough bits and pieces are separable to extract much of the constant part, but I don't think it's very interesting to the spooks. I mean, I think they already have what they need there pretty early on. But if you configure it and the clients to favor ephemeral keys you reduce the usefulness of captured traffic in being able to simulate the server itself. And give them even more to work from. Sure. I mean, yes, they are trying various ways to find the keys people are using, but those aren't the big fish. Especially since we have to assume that the hardware entropy generators in the CPUs for the most popular CPUs are pretty much under the control of one set of spooks or another. I mean, yeah, they probably have the resources to simulate the debian download infrastructure in their internal server farms, but why do their work for them and free their resources up for other jobs? I'm not sure that's a realistic scenario. Why not? Especially when the only real advantage of using TLS download transport is (the illusion of) being able to download what you want without them knowing exactly what you downloaded. Yeah they could probably infer it based on the session size. Uhm, yeah, that's another trick they have available. But in many cases, they don't even need to do that. They do that for other encrypted streams, like determining successful SSH logins. But TLS also serves as a sort of sloppy authentication mechanism, assuring you that someone someplace has vouched for the fact that you've connected to the system you intended to connect to. It's not terribly useful when you already sign your packages, but layers etc. I myself use the argument of added low walls and speed bumps when we are talking about skript k!dd13s, but low walls are not such a wonderful strategy when we turn our attention to professionals. It's pushing a metaphor, but a low wall can sometimes be another place for a spook to hide. As someone pointed out, verifying the mirror we've connected to is not useful when we don't particularly have, or want, a way to prevent a spook-owned mirror from joining the pool. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43iotff6hdoy7es4pv2jpjcw5zveukfcgpkhrk_n2e+1...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 5, 2014 at 6:14 AM, Hans-Christoph Steiner h...@at.or.at wrote: [...] I'm with Lou on this one, I'm not surprised. there are already much bigger and better data sets for that. So we should give them even more? According to this paper[1], Fedora 11+, Red Hat, SUSE, Google updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and others all use HTTPS for their updates. Pardon me for being obnoxious, but do you really need to refer to someone else's research[1] for that little gem? Well, I suppose, if we were on the user list, we might assume that some of those participating might not be using those tools, or might not be noticing what they are downloading. In which case, it would be nice, if you were assuming such, to provide a page/paragraph/table/etc. number, such as Table 2, found in section 5, on p. 5 of http://freehaven.net/~arma/tuf-ccs2010.pdf (Or of https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf. I guess the reason you gave me two links to the same paper is so that if one is unreachable we might be able to get to the other?) Debian is behind the curve here, So we aren't fashionable? HTTPS for updates is becoming the norm. Lemmings, everyone? Plus if the HTTPS it set up with Forward Secrecy ciphers, the keys are frequently rotated. The MacGuffins? But what is the Holy Grail for them? (Yeah, Holy Grails are also MacGuffins, but keys are red herring-style MacGuffins here.) And on the flipside of Joel's argument, right now, the NSA tries to store as much encrypted data as possible. They admit as much. That way when they get the key later, they can go back and decrypt old traffic. Do we really think that's the only reason they store it? So generating more HTTPS traffic means they can't keep up as much. Hmm. I wonder which they are going to have an easier time budgeting -- adding more off-line storage or adding more on-line CPUs+storage? You do understand that emulating distribution networks takes CPUs? But this is probably not really important in this case since they would probably notice that the sites are mirrors and ignore the traffic. ??? .hc [1] http://freehaven.net/~arma/tuf-ccs2010.pdf or https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPovcP-xFj+RKJfeGh4u+YgYKRdRRFEkuw9o9hzAoj=l...@mail.gmail.com
Re: Please remove me from this list
On Sat, Jun 28, 2014 at 12:45 AM, [...] I know, I am a jerk, but it was the first thing I thought of I don't think that makes you a jerk at all. We are all jerks at times. It's part of being human and not understanding the other guy's situation. IMHO one of the most serious deteriorations in our profession has been the rise of slapdash, non-technical, shoot-from-the-hip people to positions of power and control. Raising your eyebrows at this trend does not make you a jerk. It might make you humourless, but I'm sure that just applies to me :) Trend? Bill Gates? Steve Jobs? Trend, maybe, but nothing particularly new. Managers manage by charisma more than by technical skill, even in the best cases. [...] -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imuuwazfrshefemdilmzku4rrpdapia8dbr8b0jk0i...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sat, May 17, 2014 at 8:44 PM, Patrick Schleizer adrela...@riseup.net wrote: Joel Rees: He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features That's a good list of all the currently fashionable security features for Linux. Some of the items in the list are meaningful, some are not. Most might be if you know what you are doing with them. None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. The problem is, that Debian lacks a page similar to: https://wiki.ubuntu.com/Security/Features Is that page really useful? I mean, besides as a sort of sales brochure? As you can see, that https://wiki.ubuntu.com/Security/Features page looks impressive to new users. I guess Debian is losing a few users to Ubuntu, because Debian does not have such a page. I did note that the debian pages on security are a bit dated. I suppose I should lend a hand there if I can find the time. How about you, do you have the time? You don't have to start out understanding the whole list, you just have to be willing to look up the debian packages, learn how their setup works, and write down what you learned, discuss it on the appropriate lists, then write up some summaries and submit them. If you do good work, you'll be invited to assume responsibility for some of the wiki pages. This will be an issue with any OS you choose, even seriously secure OSses like openBSD. Is OpenBSD a seriously secure OS? I suppose it's easier to get into an openbsd server than it is to fly to the moon, but if you set up an openbsd server and keep it updated, attackers will generally find it easier to try social engineering instead of attacking the server directly. Modulo the services you run, but that's true of any OS. If you are running a hypertext protocol server and it has a hole, you have a hole in your server. Last time I checked, OpenBSD didn't provide signed packages for the package manager by default. Using OpenBSD signed packages for updating only seemed ridiculously complicated. Basically, you're supposed to buy the CDs from the project. CDs are a bit harder to spoof than dns, and they come out every six months. http://www.openbsd.org/faq/faq1.html: OpenBSD is thought of by many security professionals as the most secure UNIX-like operating system Well, for experts eventually, not for normal users! There is no operating system that is secure for people who aren't willing to learn how to admin the thing. And I am wondering which security professionals they are quoting and from when these quotes are. Search the web. Do not surf the web as root or as any administrator login id, of course. Speaking of admin login ids, it's a good idea to have one non-root login id that you only use for administrative tasks. And you should avoid getting onto the web when logged in with the admin id. Which means you need another id for general use, which makes two strong passwords, three if you allow root login. After reading the following blog post http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html it seems to me, that user account level isolation isn't very strong. That's why you don't surf the web as an admin user. There are lots of things I left out, to avoid dropping an elephant on the list. One is that you should avoid X11 user switching in general, and especially when you are doing admin work.. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43imw52ab6xtuf2imxtrerrdkrzylthb22cq2-nipccn...@mail.gmail.com
Re: Debians security features: Which are active?
On Sat, May 17, 2014 at 7:38 PM, herzogbrigit...@t-online.de herzogbrigit...@t-online.de wrote: Thank you for all your replies. I understand that the user is important for security, but it's a difference whether you start from scratch or you can work with somethink prebuilt. So, could you tell me, which of the following securit features are enabled in Debian by default and which I have to activate manually: Just curious, but did you click on any of these (or scroll down the page)? For Debian, you can find a lot of your answers here: https://wiki.debian.org/Hardening You will note that a lot of these features are currently enabled by default via the use of current gcc. That is, many of these things were pioneered by various OSses, including Debian, then adopted into the gcc compiler tools, and then tested again as the OSses brought the new versions of gcc in. [...] -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPSpZ_avA7d4-BWfLokjr22ioRN5tn�afhsbymhe...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
Heh. I took the bait on this one. On Sat, May 17, 2014 at 8:44 PM, Patrick Schleizer adrela...@riseup.net wrote: Joel Rees: He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features That's a good list of all the currently fashionable security features for Linux. Some of the items in the list are meaningful, some are not. Most might be if you know what you are doing with them. None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. The problem is, that Debian lacks a page similar to: https://wiki.ubuntu.com/Security/Features [...] Scroll down that page to the bottom. I'd say that lacks seems to be a bit of a strong word to use there. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iPOcda72JuhZofyKOcg6NM1=rnmj34mz931b0rwxyz...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sat, May 17, 2014 at 10:39 PM, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Sat, 17 May 2014 11:44:56 + Patrick Schleizer adrela...@riseup.net wrote: After reading the following blog post http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html it seems to me, that user account level isolation isn't very strong. A very helpful link. I wasn't aware of that problem until now. Is there anything I can do against this, without using two different users? Are there any plans on changing this behaviour? There are more reasons than the X11 hole to refrain from using your admin user to surf the web. If you are worried about needing to find answers to admin problems by searching the web, lynx helps somewhat. But I still restrict the places I visit with lynx while running as an admin to my search engine site, certain subdomains of debian.org, and such. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMn2QnuB28=hrq+jf_ngwkof4md1zpph79kte_resg...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sun, May 18, 2014 at 12:34 AM, Richard van den Berg rich...@vdberg.org wrote: Joel Rees wrote On 17-05-14 03:19: He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. I might be misinterpreting your definition of meaningful, but I have been looking for a public entropy source for my Debian system for quite a while. If you can point me to the Debian equivalent of pollinate and https://entropy.ubuntu.com/ that would be highly appreciated. Hmm. Early boot has problems getting enough randomness (for what?), so let's go get some randomness from a server somebody in the Ubuntu project set up. Pardon me for being cynical, but what could go worng? But the client is supposed to be 50 lines of golang, is it not? -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMberAfPyOnx91eXj-AJQeF1SO+O=w_68txw4zkmbi...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sat, May 17, 2014 at 11:18 PM, Reid Sutherland r...@vianet.ca wrote: That's a good list of all the currently fashionable security features for Linux. Some of the items in the list are meaningful, some are not. Most might be if you know what you are doing with them. None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. The problem is, that Debian lacks a page similar to: https://wiki.ubuntu.com/Security/Features As you can see, that https://wiki.ubuntu.com/Security/Features page looks impressive to new users. I guess Debian is losing a few users to Ubuntu, because Debian does not have such a page. Again, Debian is not in the business of handholding new Linux users, nor should it be. Debian is a foundation for targeted systems. Just for the record, https://wiki.debian.org/Hardening Yeah, I missed that at first, too. Sorry. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ioisau6sian7jng6n_htxsvt2sbpw9rzkyvct+ardx...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sun, May 18, 2014 at 1:24 AM, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Sun, 18 May 2014 01:09:06 +0900 Joel Rees joel.r...@gmail.com wrote: On Sat, May 17, 2014 at 10:39 PM, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Sat, 17 May 2014 11:44:56 + Patrick Schleizer adrela...@riseup.net wrote: After reading the following blog post http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html it seems to me, that user account level isolation isn't very strong. A very helpful link. I wasn't aware of that problem until now. Is there anything I can do against this, without using two different users? Are there any plans on changing this behaviour? There are more reasons than the X11 hole to refrain from using your admin user to surf the web. Just out of curiosity, what are these reasons? Your browser and any plugins, addons, etc. that it loads, including java, flash, java/ecmascript, and, well, any scripting language the browser can be running, for starters. Shoot, if my memory serves me, I seem to remember a class of vulnerabilities that has never really been answered, involving pushing keyboard loggers into the keyboard controller itself. If you are worried about needing to find answers to admin problems by searching the web, lynx helps somewhat. But I still restrict the places I visit with lynx while running as an admin to my search engine site, certain subdomains of debian.org, and such. I'm not only worried about my admin account. This is still a big security-hole for non-admins. The web is not safe. If you do internet banking, at least make a separate, dedicated account for that, too. And if you go places where maybe you should not let you go, re-think your reasons for going. I get a lot of flack for such suggestions, but I'm not going to tell you soft stories. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43in3xzmh9wfmuwkujtbkhdj1gervb2uq5hvbnxd7wgt...@mail.gmail.com
Re: Dedicated admin account (was Re: Debians security features in comparison to Ubuntu)
On Sun, May 18, 2014 at 1:50 AM, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Sun, 18 May 2014 01:36:44 +0900 Joel Rees joel.r...@gmail.com wrote: There are more reasons than the X11 hole to refrain from using your admin user to surf the web. Just out of curiosity, what are these reasons? Your browser and any plugins, addons, etc. that it loads, including java, flash, java/ecmascript, and, well, any scripting language the browser can be running, for starters. Shoot, if my memory serves me, I seem to remember a class of vulnerabilities that has never really been answered, involving pushing keyboard loggers into the keyboard controller itself. If you are worried about needing to find answers to admin problems by searching the web, lynx helps somewhat. But I still restrict the places I visit with lynx while running as an admin to my search engine site, certain subdomains of debian.org, and such. I'm not only worried about my admin account. This is still a big security-hole for non-admins. The web is not safe. If you do internet banking, at least make a separate, dedicated account for that, too. And if you go places where maybe you should not let you go, re-think your reasons for going. So basically I would need one account for surfing, one for online-banking, ssh(-agent) and other important stuff and an admin-account. Some accounts I missed? I know that's not gonna help, but I fell like there should be a better way to isolate processes. There are some experiments in sandboxing in the browser, other, more general experiments in sandboxing apps in general. Somebody mentioned Qube or some such. Openbsd is partially mitigating the X11 hole with some interesting stuff. I have a poor-man's sandbox that I blogged about several years back, but I got it wrong relative to X11, if I remember right. I suppose I should do some testing and update my blog, but nobody's read that post in the last year, I think. But that method, involving sudo, does, at least, isolate the javascript code and the cookies. If you have a million dollars to front a project for the next three years and feed me and my family and about ten developers, I might be able to produce a Linux or BSD derivative that allows you to log in as one user and fire up ephemeral users for tasks. The bulk of the development is going to go into isolating the video buffers, I think. And the resulting video will be slow, probably won't be able to use most of the current hardware acceleration. I jest. I have other things I want to do. Cheaper and quicker to just get used to separating what you do and how you log in. Well, xen or one of the other VMs might help. But I'm not sure even those will properly isolate the video buffers to avoid screen-scraping. PS: Please don't CC me Sorry about that. I usually remember to delete the sender. Too lazy to set up a proper MUA for mailing list access. -- Joel Rees Computer memory is just fancy paper, the cpu and i/o are just fancy pens. This is not the magic you are looking for. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ios-hxrketyaymyetxcgux33ym59_v5m5evn3m-+v7...@mail.gmail.com
Re: Debians security features: Which are active?
So, ... On Sun, May 18, 2014 at 2:32 AM, herzogbrigit...@t-online.de herzogbrigit...@t-online.de wrote: Paul Wise recently started a thread on this mailing list: goals for hardening Debian: ideas and help wanted What about making a wiki page in Debian wiki listing what's implemented with references? If you wish, I can try to start that table. I would be interested myself what's implemented. Yes it would be great if you can start with such a page. Use the Ubuntu table as a template to start. I'll try to help as much as I can in the wiki. Many Linux-Distros have a security features page in their wikis. So why not also Debian? Has anyone yet noticed this page: https://wiki.debian.org/Hardening It's linked from the Ubuntu page that Brigette started with, and shows up fairly high in google searches. You probably won't think it's sufficient, but it would be a great place to start from. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43io0ufd3hrp+vbqyqq5ovm1bzairz+bm8hnkahat4d2...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sat, May 17, 2014 at 6:41 AM, Reid Sutherland r...@vianet.ca wrote: [response shifted to conversational format] On May 16, 2014, at 3:38 PM, herzogbrigit...@t-online.de wrote: Hello there, I'm a new user of the great Debian distro for my Desktop. But when I talked to a friend and I told him, that I'm using Debian (Wheezy) for my desktop computer, he told me that I shoudn't use it because it is not secure. He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features So, I'm very happy with Debian but because my friend seems to be an expert for Linux, I don't know if I can use Debian. Can you tell me which of the security features promoted by Ubuntu are also enabled in Debian? Thank you very much! Brigitte Herzog From my view, Debian is designed to be flexible and does not impose any unnecessary features on the user. For this reason, I find it is best for new users to operate distributions that are more targeted to their needs. Distributions such as Ubuntu come with reasonable defaults for the market they are supporting (desktop / office users in this case), while Debian is more of a base system offering “factory” defaults that are usually customized by more experienced users. The same idea can apply to the various security layers added to the system, Ubuntu may activate these layers by default, while Debian will defer these decisions to the user. While there is a point to the idea that distros like Ubuntu and Mint are set up more oriented towards the beginner or the user who doesn't want to waste time on system administration, it is highly questionable whether certain of the added security features actually increase security. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNaDfhpRZ_w=tcennddh7wl++6kzpcs+t3w8mdx1jr...@mail.gmail.com
Re: Debians security features in comparison to Ubuntu
On Sat, May 17, 2014 at 4:38 AM, herzogbrigit...@t-online.de herzogbrigit...@t-online.de wrote: Hello there, I'm a new user of the great Debian distro for my Desktop. But when I talked to a friend and I told him, that I'm using Debian (Wheezy) for my desktop computer, he told me that I shoudn't use it because it is not secure. Maybe he meant that he didn't figure you could secure your Debian system as well as Ubuntu secures the Debian system for some definition of average user. (Are you the average user that the Canonical team imagines?) Otherwise, he was telling you that Ubuntu is secure even though the foundation of Ubuntu is not. Which is not the case, at any rate. He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features That's a good list of all the currently fashionable security features for Linux. Some of the items in the list are meaningful, some are not. Most might be if you know what you are doing with them. None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. So, I'm very happy with Debian but because my friend seems to be an expert for Linux, I don't know if I can use Debian. Can you tell me which of the security features promoted by Ubuntu are also enabled in Debian? Security is not a package you can buy or download. Whether you choose Ubuntu or Debian, if you are concerned about security, you need to spend time learning about it The partly out-of-date pages that Riku gave you links to are a good place to start. The first question I would ask (but don't answer me, of course) is how good your passwords are. This will be an issue with any OS you choose, even seriously secure OSses like openBSD. Your passwords should be at least ten characters, preferably twelve or more, include alphabet and numbers and one or two punctuation marks. One I used to use was something like MIro$0fT5t!NKs. But don't use that, of course. (When I realized that too many people know my prejudices, I decided I shouldn't use it.) The next question is whether you allow root login. (Again, don't answer me, on or off list. Just check yourself.) If you allow root login at all, use an extra strong password for root. You probably do not want to allow root login from the network, but you may want to allow root login from the console. Changing the port sshd listens to is also a good idea. Do not surf the web as root or as any administrator login id, of course. Speaking of admin login ids, it's a good idea to have one non-root login id that you only use for administrative tasks. And you should avoid getting onto the web when logged in with the admin id. Which means you need another id for general use, which makes two strong passwords, three if you allow root login. If you have a habit of downloading random apps from the internet, unlearn that habit. Use your package manager instead, and think twice or more about the apps that you can't get through your package manager. (This is turning into another blog post, I think.) Anyway, the basics of security are the same, whether you use Debian, Ubuntu, Fedora, openBSD, whatever. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43inlxo_dxsp_b+q1mxuunyefuynycej_mqw3bkrw+ys...@mail.gmail.com
Re: Four people decided the fate of debian with systemd. Bad faith likely
On Sun, Mar 2, 2014 at 10:00 AM, y...@marupa.net wrote: On Sunday, March 02, 2014 09:20:44 AM Joel Rees wrote: On Sun, Mar 2, 2014 at 8:43 AM, y...@marupa.net wrote: On Sunday, March 02, 2014 12:00:41 AM Volker Birk wrote: On Sat, Mar 01, 2014 at 02:17:05PM -0800, Leslie S Satenstein wrote: I am a casual Debian user and a person who has 50 years in IT. My first comment is that the direction that other Linux distributions are taking is not the system V direction. I am not a Linux Internals person, but there are many who are. The consensus is that systemd is better and the right approach for now and the future. I realize that the author of this email to which I am responding is upset. But, what should be done? Do a fork of Debian and that fork remains with Sys V? There will be a split in Debian community for this decision for sure. The split goes through Linux community in total. Doesn't make the decision to drop SysV Init, a system even its own maintainer says is a pile of garbage, in favor of systemd, any less technically sound. flame away, flame away Call it a flame all you want, It was a flame, and a flame empty of reason. You provided a much more reasonable, if short-sighted, description of your position in another post. You can do that. If you're going to respond to the kind of post that started this thread, you should respond with reason. Unless you really don't care for reason. If you couldn't respond with reason, why bother responding? I for myself will switch to DragonFly BSD if possible. The problem is, that Linux today has the drivers. And because the political program of the systemd guys to conquer the whole Linux world is successful, everyone will be dependent on their APIs there in near future. Oh please, grow up. You grow up. Technically inferior stuff always seems to get the money, but you get to live in the results of your choices. Oh, how will I ever live with a faster boot, more reliable process control, unit files that are easier to write and maintain than initscripts, socket- activated daemons, concurrently-launched dependency-based service startup, the fact that I use Archlinux and it actually went FROM a BSD-style init TO systemd, a logger I can actually efficiently navigate with metadata, and a more unified device and configuration infrastructure? Life is so horrible for me thanks to how easy systemd makes maintaining my system. I have seen the light! Conrad Yeah, it works fine for you for now. You will understand what I have said soon enough. shrug/ -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iO+rHTDfbRHCKFAAjyaER78OhJY_-Z18SeKgy=3z+k...@mail.gmail.com
Re: Four people decided the fate of debian with systemd. Bad faith likely
On Sun, Mar 2, 2014 at 8:43 AM, y...@marupa.net wrote: On Sunday, March 02, 2014 12:00:41 AM Volker Birk wrote: On Sat, Mar 01, 2014 at 02:17:05PM -0800, Leslie S Satenstein wrote: I am a casual Debian user and a person who has 50 years in IT. My first comment is that the direction that other Linux distributions are taking is not the system V direction. I am not a Linux Internals person, but there are many who are. The consensus is that systemd is better and the right approach for now and the future. I realize that the author of this email to which I am responding is upset. But, what should be done? Do a fork of Debian and that fork remains with Sys V? There will be a split in Debian community for this decision for sure. The split goes through Linux community in total. Doesn't make the decision to drop SysV Init, a system even its own maintainer says is a pile of garbage, in favor of systemd, any less technically sound. flame away, flame away I for myself will switch to DragonFly BSD if possible. The problem is, that Linux today has the drivers. And because the political program of the systemd guys to conquer the whole Linux world is successful, everyone will be dependent on their APIs there in near future. Oh please, grow up. You grow up. Technically inferior stuff always seems to get the money, but you get to live in the results of your choices. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNquRx-Dbv0=061-6-kxw_d0Tcbc+fW1zwLgox-T=1...@mail.gmail.com
Re: MIT discovered issue with gcc
On Sun, Dec 1, 2013 at 9:26 AM, Bernhard R. Link brl...@debian.org wrote: * Joel Rees joel.r...@gmail.com [131129 00:36]: The standard needs to be re-written to encourage sane behavior in undefined situations, and if you don't like that opinion, I'll take some time later, when I have some, to rip your arguments that I've clipped above to shreds. I don't mind if you don't. I think the only answer to those lines is to advise you to not use any programs written in C. Heh, heh, heh I suggest writing everything in Haskell and compiling that to java byte code run in a jvm. With the jvm implemented in Haskell and running in an interpreter. touche (Where is the unicode palette when you want an accented e?) Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC I went back and started digging into the threads Mark posted way back up there, and the grad student (I think it was) at MIT is just really taking things way out of context. So is most of the thread, including my earlier reactions. The compiler writers, including the team working on LLVM/Clang, are fully aware that the appropriate behavior when a compiler optimizes based on undefined behavior is to provide for issuing warnings. Getting there is just a bigger step than they realized. I need to take the time to add to the confusion with a blog post of my own interpretation, I suppose. A lot of strange things got said, mostly by people who don't seem to be directly involved in writing the optimizing code. (No, the standard theoretically allowing bats to fly out of unpredicted places when undefined code is executed is not an optimizer's excuse to silently kill undefined behavior code. The standard does not say that, really. I'm not sure why people like to (mis)quote that misinterpretation. And there does some to be some lack of awareness that treating undefined behavior code the same as dead code is a false inversion of logic. But the guys doing the optimizations are mostly trying to avoid treating undefined behavior code that way, really.) But the point that a lot of C programmers, even experienced programmers, don't really understand the languages they are using when writing in C probably bears a bit more emphasizing. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iNm4rbvNW1F6KM1-RU1Zq+=SFzwcMcXnbbA7Xb7X8=n...@mail.gmail.com
Re: MIT discovered issue with gcc
of optimization. What about adding cppcheck warnings and gcc -Wall -pedantic be added to Lintian? Or what about changing debhelper to pass some -f flags by default? I'm thinking the standards committee needs some fresh blood. It's well past time for the standard to recognize the difference between undefinable behavior and system dependent behavior, and to encourage compiler writers to put warnings about system dependent behavior at a higher priority than arbitrary optimizations. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iN9vzx63g0vOdFLbtGq24St42-X=29q1u8zjgo2jpf...@mail.gmail.com
Re: MIT discovered issue with gcc
On Fri, Nov 29, 2013 at 3:02 AM, Bernhard R. Link brl...@debian.org wrote: * Octavio Alvarez alvar...@alvarezp.ods.org [131127 21:28]: [...] As people want fast programs it makes sense in my eyes to say here: This modification has big advantages and only is a problem for programs already not supposed to work by the standard. So, since people want fast cars, we should re-write our standards to ignore safety because the driver did something stupid? I'm against seatbelt laws, myself, how about you? Once upon a time, the standard included words to the effect that undefined behavior should at least remain sane for the implemented run-time for some definition of sane. That should part seems to have been thrown away in an effort to compete for speed. And with whom are we competing so mindlessly? The standard needs to be re-written to encourage sane behavior in undefined situations, and if you don't like that opinion, I'll take some time later, when I have some, to rip your arguments that I've clipped above to shreds. I don't mind if you don't. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iMk9sTXQhY=V+OFHA0iAftamOkGNw3Hqu81aisc=iq...@mail.gmail.com
Re: MIT discovered issue with gcc
Deja gnu? On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote: Hi, The following link shows the issue in a nutshell: http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c [it refers to the PDF that I mentioned] -- Kind Regards AndrewM I seem to remember discussing the strange optimizations that optimized away range checks because the code that was being firewalled had to be correct. Ten years ago, it was engineers that understood pointers but didn't understand logic. This time around, maybe it's a new generation of sophomoric programmers, or maybe we have moles in our ranks. The sky is not falling, but it sounds like I don't want to waste my time with Clang yet. And I probably need to go make myself persona non-grata again in some C language forums -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43io_4l7+vil8vqzpzro+fdm1vhpphepomp88hiwbn+f...@mail.gmail.com
Re: MIT discovered issue with gcc
[Not sure this really needs to be cc-ed to security@]
On Sun, Nov 24, 2013 at 12:09 AM, Robert Baron
robertbartlettba...@gmail.com wrote:
Aren't many of the constructs used as examples in the paper are commonly
used in c programming. For example it is very common to see a function that
has a pointer as a parameter defined as:
int func(void *ptr)
{
if(!ptr) return SOME_ERROR;
/* rest of function*/
return 1;
}
Isn't it interesting that their one example will potentially dereference the
null pointer even before compiler optimizations (from the paper):
struct tun_struct *tun=;
struct sock *sk = tun-sk;
if(*tun) return POLLERR;
The check to see that tun is non-null should occur before use, as in - quite
frankly it is useless to check after as tun cannot be the null pointer (the
program hasn't crashed):
This one has been thrashed to death.
Yes, the standard (after considerable reworking overseen by certain
groups with an axe to grind) says that, not only is dereferencing
before testing evil (i.e., undefined), but even adding to a pointer
before testing it is evil.
Committees really should not be allowed to define language semantics.
Make suggestions, sure, but actually define them, no.
struct tun_struct *tun=;
if(*tun) return POLLERR;
struct sock *sk = tun-sk;
Yes, this arrangement is less liable to induce error on the part of
the programmer.
The compiler should be immune to such issues of induced error,
especially if it is able to reliably optimize out theoretically
undefined code (which is seriously, seriously evil).
I am under the impression that these problems are rather widely known among
c programmers (perhaps not the kids fresh out of college). But this is why
teams need to have experienced people.
Furthermore, it is very common to find code that works before optimization,
and fails at certain optimization levels. Recently, I was compiling a
library that failed its own tests under the optimization level set in the
makefile but passed its own test at a lower level of optimization.
Completely separate issue.
PS: I liked their first example, as it appears to be problematic.
As I noted (too obliquely, perhaps?) the my comments why you
top-posted over, this is nothing at all new. The holy grail of
optimization has been known to induce undefined behavior in compiler
writers since way before B or even Algol.
The guys responsible for optimization sometimes forget that falsifying
an argument is not falsifying the conclusion, among other things.
On Sat, Nov 23, 2013 at 8:17 AM, Joel Rees joel.r...@gmail.com wrote:
Deja gnu?
On Sat, Nov 23, 2013 at 10:34 AM, Andrew McGlashan
andrew.mcglas...@affinityvision.com.au wrote:
Hi,
The following link shows the issue in a nutshell:
http://www.securitycurrent.com/en/research/ac_research/mot-researchers-uncover-security-flaws-in-c
[it refers to the PDF that I mentioned]
--
Kind Regards
AndrewM
I seem to remember discussing the strange optimizations that optimized
away range checks because the code that was being firewalled had to
be correct.
Ten years ago, it was engineers that understood pointers but didn't
understand logic. This time around, maybe it's a new generation of
sophomoric programmers, or maybe we have moles in our ranks.
The sky is not falling, but it sounds like I don't want to waste my
time with Clang yet. And I probably need to go make myself persona
non-grata again in some C language forums
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAr43iMM1OuT_cxYADAophvNtT95VxP=bfj+-nosgp+7agf...@mail.gmail.com
Re: MIT discovered issue with gcc
On Sun, Nov 24, 2013 at 12:18 AM, Robert Baron robertbartlettba...@gmail.com wrote: Second question: Doesn't memcpy allow for overlapping memory, but strcpy does not? Isn't this why memcpy is preferred over strcpy? [...] The reason memcpy() is preferred over strcpy() is the same as the reason strncpy() is preferred over strcpy(). memcpy() is actually considered a no-no in some circles, and perhaps correctly so. (Especially in C++, where classes are supposed to define their own copying, and it's almost always more optimal to explicitly copy each member instead of calculating the size, mass copying, and going back and overwriting the members that are subject to issues like deep copy. Remember that memcpy() is able to copy an odd number of bytes, so the size calculation contains a bit more than is obvious to the programmer.) -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43iof7wca3zugtzewvhddjzk98ava2oatgw_mavruoyz...@mail.gmail.com
Re: debian wheezy i386 nginx iframe rootkit
On Thu, Sep 12, 2013 at 9:39 AM, E Frank Ball III fra...@efball.com wrote: On Thu, Sep 12, 2013 at 09:13:46AM +0900, Joel Rees wrote: On Thu, Sep 12, 2013 at 7:48 AM, E Frank Ball III fra...@efball.com wrote: Last fall there was a debian 64-bit / nginx rootkit going around, now I've been hit with what sounds similar but on 32-bit wheezy. All files served by nginx have this line inserted at the top: iframe src= http://122.226.137.123:/yixi.exe width=0 height=0/iframe I tar'd up /lib/modules/3.2.0-4-686-pae/kernel, copied it to another Debian Wheezy i386 machine in a safe environment and did a diff -r. No difference. No ismod line in /etc/rc.local I haven't been able to find anything. Googling doesn't show anything similar for debian wheezy i386, only sqeeze 64-bit. I was using nginx-light from dotdeb.org. I uninstalled nginx and tried the nginx-light from debian wheezy but it made no difference. Just out of curiosity, did you back up nginx and check it as well? -- Joel Rees No, I just uninstalled nginx from dotdeb and installed from Debian. I suppose you're wondering whether to regret that? The webpages are all static and remain unchanged, the nginx config files are OK. The new line is added by some process I can't find. No surprise in that. Malware is getting better at hiding itself these days. The lynx webrowser shows this as the first line of the webpages: Local on the machine in question or external? IFRAME: http://122.226.137.123:/yixi.exe It also appears in downloads using wget. view source in firefox or chrome show nothing amiss. It only appears on IPv4, not IPv6. Again, are the browsers local to the machine in question or accessing from the network? I do not have php installed. Good. I enjoyed programming php, but if you can't trust the engine, it's hard to justify writing an app on it. The http header is completely different: curl -I shows this: HTTP/1.1 200 OK Content-Type: text/html; charset=en_US.UTF-8 Content-Length: 3634 When it should look more like this: HTTP/1.1 200 OK Server: nginx/1.4.2 Date: Wed, 11 Sep 2013 23:39:48 GMT Content-Type: text/html; charset=en_US.UTF-8 Content-Length: 3291 Last-Modified: Thu, 24 Jan 2013 21:30:28 GMT Connection: keep-alive Vary: Accept-Encoding ETag: 5101a7f4-cdb Accept-Ranges: bytes Okay, so, if it isn't something on an external box hijacking the IP address of the box in question, it's a local process or set of processes hijacking port 80 and trying unsuccessfully to be a pass-through proxy. I installed chkrootkit, rkhunter, unhide.rb and they found nothing. E Frank Ball fra...@efball.com Well, installing those after the unknown software is in place kind of makes it hard for them to do their jobs. Among other things, the system file map and checksums are going to reflect the unknown state rather than the known good state. Of course, if you have a serious rootkit in place, it's going to hijack your detection/removal tools as soon as it sees them, so those tools are not 100% infallible under the best conditions. How much time/resources can you afford to spend on trying to pin the intrusion vector down? Although, I'd hesitate to use the box for anything important, even after a complete wipe/install, unless the BIOS can be safely restored from a write-protected backup image. And I'd try to be careful enough during the install that if the exploit were repeated, I'd notice immediately and thus be able to pin the thing more closely. Maybe build the server as a VM and take snapshots as you go. Or rebuild it on a different machine, with the old server reboot from a live CD before each major step and use the tools on the live CD to take the snapshots. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iM3=JZ3RFiFAgVi7_qnGh8tZD0NV3Z-1ktye5_jUb=k...@mail.gmail.com
Re: How secure is an installation with with no non-free packages?
On Fri, Sep 13, 2013 at 8:42 AM, adrelanos adrela...@riseup.net wrote: adrelanos: How secure is a Debian installation packages installed only from main, none from contrib or non-free? It will lack for example the firmware-linux-nonfree package and the intel-microcode / amd-microcode package. At least the microcode one is security relevant? Are there any other packages which might be important to have installed for security reasons? I mean, how secure is it in comparison with those packages installed vs not having them installed? I apologize, I didn't want to start a discussion of Open Source vs closed source. (Feel free to have it, I am delighted to read your thoughts on it, but I'd be also happy about an answer to the question I meant to ask but failed to properly state.) Sorry for not asking clear in the first place. To rephrase my original question: How vulnerable is Debian installation without intel-microcode / amd-microcode package? No one knows. We can only guess. Our guess includes an assumption that Intel or AMD would or would not deliberately sabotage their products at the instigation of an organization like the Chinese/Taiwanese government or the NSA or some similar equivalent or not-so-equivalent secret organization. Ken Thompson gave us the archetype response on this question when he described a way to grandfather a backdoor password into (the libraries used by) a C compiler such that it would not show in the source but would be present in the object. I assume you have read his essay on trusting trust? (1) All we can say for sure is that anything that is open is inherently more open than anything that is closed. (2) Anything we didn't build ourselves may be deliberately sabotaged. (3) Anything we do build ourselves will have accidental gaping holes. (4) When we work with friends, we can do more than when we work alone. None of that tells us how bad Intel and AMD are screwing up, and which directions they are running with the ball in the hardware camp. They are primarily concerned with features that sell or otherwise obviously make them money. Until sometime in the future (closer now than a year ago), security does not sell, does not obviously make them money. rant-mode That's the short-sightedness of capital based economy when interest-holders are not well-versed in the technological details of a company's products or of the impact that product has in the market and where it gets used. I hate to bring up the G-word again, but we humans work beyond the edge of our abilities, we end up depending on someone being more than human. And we refuse to accept the limitations of working within our abilities, just like we refuse to believe we are as limited as we are. Fortunately, G?? (or the universe) seems to have given us room to make mistakes in this way, up to a point. Our next big mistake is to hope that the natural consequences (or punishments of G??) will never catch up to us. /rant-mode Are there other contrib and/or non-free packages, similar to the microcode package, which make the system vulnerable, if not installed? Depends on what you're using the system for. Wish I could say more, but we are really just barely beginning to scratch the surface of building a stable computer technology. And the big boys are all about intellectual property right now, and as long as they are playing those games, we aren't going to get any further on what you need to be able to answer that question, essentially a database of function vs. package vs. target use, and the interplay thereof. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iN-ieCCU0jQvW6Hi9qcKTbKTBnn7=shtvx89vfxseq...@mail.gmail.com
Re: How secure is an installation with with no non-free packages?
I am not Debian, but I am in rant-mode on this subject today, so bear with me -- On Fri, Sep 13, 2013 at 10:02 AM, adrelanos adrela...@riseup.net wrote: Jose Luis Rivas: So no, there's no other contrib/non-free packages there. I didn't want to imply, that there are preinstalled. The reason why you can't install Debian directly from a WiFi with some manufacturers is precisely that we do not ship non-free nor contrib software by default in our Debian installation different to what does other distributions like Ubuntu (no offense meant). And this is fine and I don't want to go into that political vs convenience discussion either. You can't avoid it now. (Thanks to NSA and Intel deciding to boogie together. Let the children boogie.) So we have the (intel/amd)-microcode and the firmware-linux-nonfree package which should be installed to improve security? Are there any other packages of this type? We'd like to say they are unique. They are unique in that they are the CPU, but any binary blob required by the hardware you are using is going to have the same set of problems, and most of them, even when we move the drivers out of the kernel, are going to have the capability of subverting the whole box. We'd like to say that it's all Intel's fault for pushing the market so far so fast, but we can only say they have been a major contributor to the problem. (We have, also, each one of us.) What would you do if there was an exploit in the wild, which uses an vulnerability in (intel/amd)? Do you mean, in the cpu itself, or in the microcode? Let's say any website could prepare some html code which would trigger a remote code execution. Ergo, on vulnerable CPU/microcode combinations. One that can only be fixed by having the (intel/amd)-microcode package installed. So you're thinking the CPU, but which level of microcode? Is this a possible scenario? Of course. Especially now that the bad guys have tools that allow them to build targeted tools fairly easily. What would you (Debian) do in this case? Do you mean, would Debian fold up and go away if the only way to provide a secure OS were to be to include certain non-free packages by default? They already do (as Jose Luis Riva indicated). It just requires a certain amount of action on your part so that they can limit the amount of non-free stuff you have to load. At the very least, AMD machines do not need Intel microcode, and vice-versa. That's why it's important to have more than one major CPU vendor, even if Intel's bragging that they have beaten everyone else on all technical fronts had any merits whatsoever. (It doesn't. They haven't even come close. Their current excesses are catching up to them now.) (I am not suggesting anything here, I am just interested in those questions.) And I suppose I am not contributing anything meaningful to the conversation. Sorry, but this is a pet peeve of mine. We can't afford the results when microprocessors become this complex, and one of the reasons I hate Intel is that they have pushed the complexity so hard to maintain their market advantage, and it just makes a mess of the industry. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iMfQByPp=+O+2B0Y1JLA7Ynwu7EkvcxLygPud_3FP=c...@mail.gmail.com
Re: How secure is an installation with with no non-free packages?
On Fri, Sep 13, 2013 at 10:11 AM, adrelanos adrela...@riseup.net wrote: [...] Yes, the more I dig into one topic, the open questions remain and them stronger the conclusion we're totally screwed becomes. We've always been screwed. I'd say, ever since the 6809 faded away, but what I'd mean is ever since we moved from 8-bit to 32-bit systems. But, no, the problem is not the increased complexity, it's pushing the industry into a range of complexity where we have no tools to deal with the complexity. Don't let it turn you paranoid or cynical, just learn what you can, deal with it as you can, and keep doing what you can. And don't hope there is a magic bullet. With Intel, it's like our star pitcher has been caught trying to throw the game. I could use a war metaphor instead, but the point is not to give up. It's to adjust our ideas about whom we can trust and start adjusting our behavior accordingly. And build tools to help us contain the damage. I'm not sure what we can do concerning the microcode. The tools we need will require going against Intel's shrink-wrap agreements, but I think we can claim unconscionable clauses and such. Probing the microcode and breaking the key for the update mechanism are high-priority. It's a Pandora's box, but the NSA has forced our hand. If the ARM consortium won't help us out here, by avoiding the stupid excesses Intel has gone to, we'll eventually have to develop several industrially viable fully open/libre/free CPU cores. (Several, for specialized target applications, and so that we can avoid the monoculture issues.) -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iMaZQ639ftb0cPmTd3Rv11Vd2-G=F4uu+POqFT6O=i...@mail.gmail.com
Re: debian wheezy i386 nginx iframe rootkit
On Thu, Sep 12, 2013 at 7:48 AM, E Frank Ball III fra...@efball.com wrote: Last fall there was a debian 64-bit / nginx rootkit going around, now I've been hit with what sounds similar but on 32-bit wheezy. Here's a link to info on the previous 64-bit rootkit: https://www.securelist.com/en/blog/208193935/New_64_bit_Linux_Rootkit_Doing_iFrame_Injections All files served by nginx have this line inserted at the top: iframe src= http://122.226.137.123:/yixi.exe width=0 height=0/iframe Whatever it was isn't there anymore: Connecting to 122.226.137.123:... failed: Connection refused. I tar'd up /lib/modules/3.2.0-4-686-pae/kernel, copied it to another Debian Wheezy i386 machine in a safe environment and did a diff -r. No difference. No ismod line in /etc/rc.local I haven't been able to find anything. Googling doesn't show anything similar for debian wheezy i386, only sqeeze 64-bit. I was using nginx-light from dotdeb.org. I uninstalled nginx and tried the nginx-light from debian wheezy but it made no difference. This machine was built on July 19th. I've uninstalled nginx. I'll hold off rebuilding for now, maybe somebody here has some ideas? E Frank Ball fra...@efball.com Just out of curiosity, did you back up nginx and check it as well? -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43iojy_q8kuu47y+ah+v0e81vtnwykh2f6lvvcowqans...@mail.gmail.com
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
(Thanks for obliging, Henrik. ;-) On Sun, Sep 8, 2013 at 5:34 PM, Henrik Ahlgren pa...@seestieto.com wrote: On Sun, Sep 08, 2013 at 08:00:12AM +0900, Joel Rees wrote: (1) This requires enabling two repositories that I have been avoiding enabling, contrib and non-free. That means I have to watch the repository more carefully when using apt-cache search or synaptic to look for new tools, right? Or can we just enable those two repositories long enough to load Henrique's tool and the microcode updates, then disable them again? Why do you feel that you even need to ask? You are free to handle the situation with your machines in any way you wish. Perhaps just download and install the .deb packages directly without even using apt, or simply ignore the microcode update as shipped by Debian or as BIOS upgrades by your computer manufacturer. I'm thinking like a newbie. (Relative to debian, I am. :-/) I know there is a tendency to send newbs to Ubuntu. I don't think that's a good idea any more, for reasons you may not agree with, but I am sure you are aware of. I am subconsciously thinking about starting a new re-mix of debian that will focus on people who just want to replace MSWindows and MacOSX.whatever with something that doesn't try to own them, but don't have them time/confidence to learn how to do a manual install of a .deb package. And as long as Intel is so not-forthcoming, there is no point in doing so for x86/amd64 CPUs. (2) Are there any CPU manufacturers who are not plagued by this ultimate refusal to let computer owners actually own their computers? At least Intel openly admits that their modern CPUs have the ability to change the microcode by uploading an encrypted binary blob. This universal backdoor is publicly documented[1]. You mean, the existence and location are publicly documented, but nothing else. Other manufacturers may claim otherwise, but what else can we do except trust them? It is a very fundamental problem. And at least the mob admits they want to influence you. Ken Thompson pointed out the problems inherent in trusting machines as complex as computers. He also made some mis-targeted assertions about culpability that are very relevant. He did not provide a solution. We know the solution, but we don't want to admit that Stallman was right. We don't think we know where to go from where he takes us. (Why is decentralization so hard to understand?) Also, it is hard to argue that it is useful to have the ability to fix bugs in the CPU without replacing the chip. I think you mean, hard to argue with the usefulness? But, you see, I'm arguing that complex CPUs are evil. Somewhere in my arguments is the idea that you could produce a CPU simple enough that field upgrades would be unnecessary. After all, you will face the same dilemma of trusting the CPU manufacturer when offered a new revision of the physical CPU with bugfixes. Actually, the dilemma goes back farther than that. How can you trust the CPU manufacturer when (1) you can't see the masks and you couldn't read them if you could, (2) you can't see the manufacturing processes and you wouldn't know where to look if you could, (3) no single engineer can understand a modern CPU (and you probably aren't one of the group that could get close), (4) etc. That's more than two lemmas. Darn. It simply is not feasible for the majority of people to reverse engineer the silicon for any evil features like NSA backdoors in any hardware crypto features. And that's another set of problems. Does anyone know if the microcode shipped by Intel is always encrypted? Jack provided a link. (And Henrique brought it into this thread.) Their nasty licence prohibits everse engineering, decompilation, or disassembly of the blob, but even if you ignored that, (See said link, and kudos to someone for going that far down the road.) or even if you had the source code (whatever that means in the context of microcode, it is not normal X86 code after all), could you make any sense of it without having the whole silicon design available? Microcode source code is only a little harder to read than ordinary machine code. Sometimes it's easier. It's machine code, after all, even if it isn't the machine code the user usually works with. The problem is access to the machine that executes the microcode. Gate arrays and such are not programmed with a machine language, per se, and are significantly harder to reverse engineer. But if Intel publicly documented the gate arrays and microcoded machines used in their CPUs, the updates would not be beyond the reach of some engineers not employed by Intel. Provision of the gate array definitions and the microprogramming would add eyeballs to the job of finding bugs, as well. That leaves the manufacturing processes opaque, but even those would be more subject to probing if Intel were more forthcoming. [1] http://www.intel.com/content/www/us/en/architecture
Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
On Mon, Sep 9, 2013 at 12:55 AM, Henrique de Moraes Holschuh h...@debian.org wrote: On Sun, 08 Sep 2013, Joel Rees wrote: I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available: http://lists.debian.org/debian-devel/2012/11/msg00109.html AMD is better than Intel at telling the general public what a microcode update fixes. AMD does publish to the general public the errata each microcode update fixes. What each erratum means is also published in the AMD processor Revision Guides, which are also public. Not that it will help you much. Really. Most of the errata worth fixing through a microcode update causes either unpredictable system behaviour, data corruption, or system hangs/reboots. Only a few fixes are for minor issues such as power management, performance, or optional features. And most of the time, it is very very difficult to access how difficult it is to hit a given erratum. So it is a update or else deal, because it always fixes something horrible (even when the chances of you hitting the issue are very remote -- but you won't be able to know that, you'll have to update just in case anyway) X/ or else ..., when there are secrets being kept always bugs me. AFAIK, Intel does publish the same kind of information but it is not available to the general public. I don't really call that publishing. Publishing privately is one of the conceits introduced at Berne that undermine the principle of copyrights in free countries. Intel does publish to the general public the list of errata in their processor specification updates documentation, it just almost never writes down in public documentation what errata a microcode update fixes. And you could also have internal/non-public errata and fixes, nothing forces Intel, AMD, or any other vendor to disclose (even to their hardware partners) the full list of errata and behaviour changes (fixes, etc). Note that even the internal errata/fix information is bound to be really uninteresting anyway. Backdoors would not be documented anywhere, heck, it is very likely that only the one or two engineers that had to implement them even know about it. Still, secrecy about the microcode and about the updating machinery makes it that much harder to probe for back doors. Ken Thompson didn't mention it in his essay, but it is possible to probe library code for stuff that isn't in the source code. And it is possible to probe a CPU for backdoors, if you have enough documentation about their correct behavior. Modern CPUs (particularly x86 and AMD64) are like MSWindows -- too complex, not accessible to review, no guard rails. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- Joel Rees -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43ipy2opcbg-8ntnvwu5zeyyam4zonya+pkbxdwt514k...@mail.gmail.com
Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)
(I kind of hope this starts a flame war large enough to embarrass the corporate culprits into behaving themselves about this. Apologies in advance when I step on toes.) I was hoping that AMD was not going to have the license and non-visibility issue that plagues the Intel processor microcode updates. But I find this original announcement from when Henrique made the updater tool available: http://lists.debian.org/debian-devel/2012/11/msg00109.html And that shoots that dream. So, (1) This requires enabling two repositories that I have been avoiding enabling, contrib and non-free. That means I have to watch the repository more carefully when using apt-cache search or synaptic to look for new tools, right? Or can we just enable those two repositories long enough to load Henrique's tool and the microcode updates, then disable them again? (2) Are there any CPU manufacturers who are not plagued by this ultimate refusal to let computer owners actually own their computers? How do the ARM manufacturers do? (2a) Is debian running on any of the open core CPUs? (I don't remember any evidence of such, but maybe I just missed it?) -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43in8fkrxshhzjdehgfkep2htycwjoxexewrfayrrvzm...@mail.gmail.com
