subject:"hacked\?"

Hi,

Andrew F Comly wrote:
> E) Burn iso to media
> dd if=/dev/zero of=/dev/sdb1 bs=1M;
> wait;

Why this overwriting of partition 1 by zeros ?
The partition table will be overwritten by the ISO anyways.

(And on what asynchronous processes are you waiting to end ?)

> ddif=/media/LG/AC/bckup/Install/2_Bootable-OS/Debian/i386/debian-8.5.0-i386-l
xde-CD-1.iso of=/dev/sdb

Blanks matter. :))

Assumed that you did put a blank between "dd" and "/media", the command
would be ok for copying the ISO onto a USB stick at /dev/sdb.
(For me it runs substantially faster if i add option bs=1M.)

Did the command last long enough to be credible ?
Did it report
  1255424+0 records in
  1255424+0 records out
?

>             sudo sha256sum /dev/sdb

As we learn from the copy-to-stick command, we need to curb to 1255424
blocks of dd's default size (512 bytes per block). My USB stick is at
/dev/sdc:

  $ dd if=/dev/sdc count=1255424 | sha256sum
  ...
  fd7729e3bdfcb2b1b8793f5a19096fb2eee3cf709c39112ed2da7e7a2d7f6886  -

  $ fgrep fd7729e3bdfcb2b1b8793f5a19096fb2eee3cf709c39112ed2da7e7a2d7f6886 
SHA256SUMS
  fd7729e3bdfcb2b1b8793f5a19096fb2eee3cf709c39112ed2da7e7a2d7f6886  
debian-8.5.0-i386-lxde-CD-1.iso

Testing with ./check_debian_iso (which counts blocks of 2048 bytes each):

  $ ./check_debian_iso SHA512SUMS debian-8.5.0-i386-lxde-CD-1.iso /dev/sdc
  Piping 313856 blocks of '/dev/sdc' through 'sha256sum'
  to verify checksum list item 'debian-8.5.0-i386-lxde-CD-1.iso'.
  313856+0 records in
  313856+0 records out
  642777088 bytes (643 MB) copied, 31.7854 s, 20.2 MB/s
  Ok: '/dev/sdc' matches 'debian-8.5.0-i386-lxde-CD-1.iso' in 'SHA256SUMS'

Have a nice day :)

Thomas

Re: iso hacked suspicious: answers

2016-08-10 Thread Pascal Hambourg


Le 10/08/2016 à 17:13, Andrew F Comly   康大成 a écrit :

iso hacked suspicious: answers

Concerning the other questions re: "E-F)", please find the below answers:

E) Burn iso to media
dd if=/dev/zero of=/dev/sdb1 bs=1M;


This action is not needed. The next command will overwrite previous 
contents anyway.



dd 
if=/media/LG/AC/bckup/Install/2_Bootable-OS/Debian/i386/debian-8.5.0-i386-lxde-CD-1.iso
 of=/dev/sdb


Did you run this command as root with su or sudo ?
Apart from this it looks fine, although you could a block size of at 
least 4096 (4k) to speed up the copy.



F) Check media drive still has same sha512sum hash number


Same as what ? As before the copy (it should have changed) or as the ISO 
image file (it should be different due to different sizes) ?



sudo fdisk -l #(lookup location of burnt iso media)


What do you need to print the partition tables ?


sudo sha256sum /dev/sdb

Re: you iso's may have been hacked

Hi,

Andrew F Comly wrote:
> Am I supposed to edit the script and put something in for magic=' '?

No. Magic is what an ISO 9660 should bear at byte offset 32768:
A byte with ASCII value 1 and five bytes saying "CD001":

  $ dd if=debian-8.4.0-amd64-netinst.iso bs=1 skip=32768 count=6 | od -c
  ...
  000 001   C   D   0   0   1

Your file yielded two blanks on this shell command

  dd if="/dev/sdb" bs=2048 skip=16 count=1 |
  dd bs=1 count=6 | od -x | head -1 | \
  awk '{print $2 " " $3 " " $4}'

Wheras an ISO is supposed to yield (on little-endian machine):

  4301 3044 3130

I get two blanks as result when i apply the command to a file which does
not have 32768 bytes or to which i have no read permission.
Given the fact that you run cmp under sudo, i'd guess it is about read
permission.

To my experience, /dev/sr0 is readable for the desktop user. So one would
not experience this difficulty with optical media.


Have a nice day :)

Thomas

iso hacked suspicious: answers

2016-08-10 Thread Andrew F Comly 康大成

iso hacked suspicious: answers


#Thanks for the reminder that protonmail didn't save the two email addresses 
that I entered in the "To:" line.


Concerning the other questions re: "E-F)", please find the below answers:

E) Burn iso to media
dd if=/dev/zero of=/dev/sdb1 bs=1M;
wait;
dd 
if=/media/LG/AC/bckup/Install/2_Bootable-OS/Debian/i386/debian-8.5.0-i386-lxde-CD-1.iso
 of=/dev/sdb


F) Check media drive still has same sha512sum hash number
sudo fdisk -l #(lookup location of burnt iso media)
sudo sha256sum /dev/sdb


Sincerely,
Andrew F Comly

Re: you iso's may have been hacked

2016-08-10 Thread Steve McIntyre

Thomas Schmitt wrote:
>Steve McIntyre wrote:
>> It's also contained in the debian-role-keys keyring in the
>> debian-keyring package: [...]
>> and the full fingerprint is also on the Debian website using https for
>> people who would rather trust that.
>
>We users could easily be outsmarted in this aspect, i fear.
>It's hard to tell whom to trust and how to avoid being spoofed by others.
>
>In any case somebody with edit powers should replace in
>
>  https://www.debian.org/CD/faq/#verify
>
>"SHA1" and "MD5" by "SHA512".
>Just to make this aspect safe for the next few years ... hopefully.

Good point - I've just updated the FAQ to remove mentions of MD5 and
SHA1 and switch to SHA512 and SHA256 instead.

There's work ongoing on the new cleaner/clearer download page, and I'm
hoping to have that live soon-ish.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: you iso's may have been hacked

Hi,

Steve McIntyre wrote:
> It's also contained in the debian-role-keys keyring in the
> debian-keyring package: [...]
> and the full fingerprint is also on the Debian website using https for
> people who would rather trust that.

We users could easily be outsmarted in this aspect, i fear.
It's hard to tell whom to trust and how to avoid being spoofed by others.

In any case somebody with edit powers should replace in

  https://www.debian.org/CD/faq/#verify

"SHA1" and "MD5" by "SHA512".
Just to make this aspect safe for the next few years ... hopefully.

Have a nice day :)

Thomas

Re: you iso's may have been hacked

2016-08-10 Thread Steve McIntyre

Thomas Schmitt wrote:
>Hi,
>
>Andrew F Comly wrote:
>> gpg: WARNING: This key is not certified with a trusted signature!
>
>I wonder whom we could trust to certify the Debian gpg key ...

It's signed by a number of prominent DDs, including 2 DPLs and 2
Release Managers. Oh, and a number of idiots who don't understand GPG:
they have signed it and pushed signatures to the keyservers without
any fingerprint verification. :-(

It's also contained in the debian-role-keys keyring in the
debian-keyring package:

gpg --no-default-keyring -kvc --keyring 
/usr/share/keyrings/debian-role-keys.gpg DA87E80D6294BE9B
pub   4096R/DA87E80D6294BE9B 2011-01-05
  Key fingerprint = DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B
uid  Debian CD signing key 
sub   4096R/642A5AC311CD9819 2011-01-05

and the full fingerprint is also on the Debian website using https for
people who would rather trust that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: you iso's may have been hacked

2016-08-10 Thread Pascal Hambourg


Le 10/08/2016 à 08:36, Thomas Schmitt a écrit :


Andrew F Comly wrote:


Notice how the two sha512sum numbers (local vs burnt usb) don't match!


Of course : the image and the device do not have the same size.


Determine the ISO size on /dev/sdb by program isosize and curb its reading
by help of program dd, or try

  wget https://people.debian.org/~danchev/debian-iso/check_debian_iso

  ./check_debian_iso SHA512SUMS debian-8.5.0-i386-lxde-CD-1.iso /dev/sdb


Or use 'cmp' to compare the USB device contents with the image file.

cmp debian-8.5.0-i386-lxde-CD-1.iso /dev/sdb

If the comparison ends by reaching the end of the image file, there is 
no difference.

Re: you iso's may have been hacked

Hi,

Andrew F Comly wrote:
> gpg: WARNING: This key is not certified with a trusted signature!

I wonder whom we could trust to certify the Debian gpg key ...


> Notice how the two sha512sum numbers (local vs burnt usb) don't match!

Determine the ISO size on /dev/sdb by program isosize and curb its reading
by help of program dd, or try

  wget https://people.debian.org/~danchev/debian-iso/check_debian_iso

  ./check_debian_iso SHA512SUMS debian-8.5.0-i386-lxde-CD-1.iso /dev/sdb


Have a nice day :)

Thomas

Re: you iso's may have been hacked

Hi,

Doug wrote:

> If the md5 sum doesn't agree with what's posted, it most likely means a
> glitch in the data transmission. Download it again.

Good advise.

One has to be aware that MD5 is not considered to be safe against malicious
manipulations but only for transport safety. If one has to fear attacks,
then file SHA512SUMS.sign and program gpg --verify should be used to verify
file SHA512SUMS. Program sha512sum should then be used to obtain the SHA512
of the ISO which hopefully matches the one that is listed in SHA512SUMS.

> You can only check the md5 sum on the download. Once you
> burn it to a CD or DVD, there's no telling what the md5 sum will be.

There is one shown in
  https://www.debian.org/CD/faq/#verify

  The "isosize" program can be used to find out the appropriate amount
  of bytes to be read from the optical media. It shows the "sector count"
  and the "sector size" from the optical media, where "" is the
  device file of the loaded optical media.
$ /sbin/isosize -x 
sector count: 25600, sector size: 2048
  Then "sector count" and "sector size" are passed to "dd" to read the
  appropriate amount of bytes from the optical media and the byte stream
  is then piped to the appropriate checksum tool (md5sum, sha1sum, etc).
$ dd if= count= bs= | sha1sum
  The computed checksum is to be compared against the corresponding
  checksum found in the appropriate checksum file (MD5SUMS, SHA1SUMS, etc).

  Alternatively, there is a useful helper script called check_debian_iso
https://people.debian.org/~danchev/debian-iso/check_debian_iso
  which can verify ISO image files and optical media, reading the
  appropriate amount of bytes from media then computing the checksum and
  comparing it against the checksum file.

  ISO image file verification.
  This will compare the checksum of the debian-6.0.3-amd64-netinst.iso
  image file against the corresponding checksum found in the MD5SUMS
  checksum file.
$ ./check_debian_iso MD5SUMS debian-6.0.3-amd64-netinst.iso

  Optical media verification.
  This will compare the checksum of the media accessible as /dev/dvd
  against the checksum of debian-6.0.3-amd64-DVD-1.iso as found in the
  MD5SUMS checksum file. Note that the ISO image file itself is not
  needed, its name is merely used to locate the corresponding checksum
  in the checksum file.
$ ./check_debian_iso MD5SUMS debian-6.0.3-amd64-DVD-1.iso /dev/dvd

The proposals work for USB stick /dev/sdb too.
(It is about time this all gets updated to advise the use of SHA512.)

Have a nice day :)

Thomas

My iso may have been hacked, too!

2016-08-09 Thread Andrew F Comly 康大成

Debian users,
I would like to try out debian 8.5 lxde OS. Unfortunately after I burn (dd) to 
disk, the newly burned disk has a different hash number than the original *.iso 
file. My specific procedure is below:

===
-
Outline (Overall procedure)

A) Download SHA512SUMS and SHA512SUMS.gpg, or MD5SUMS and MD5SUMS.gpg
B) Get the key used for the signature
C) Verify the signature
D) Check the ISO with sha512sum or md5sum

-
Command outline (terse)

A) Download SHA512SUMS and SHA512SUMS.gpg from 
http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

B) Get the key
1) Display what key was used to issue the signature
$ gpg --verify SHA512SUMS.sign SHA512SUMS

2) Obtain the public key from the Ubuntu key server
To add the wanted key automatically to your keyring from the Ubuntu keyserver 
and calculate its trust:
$ gpg --keyserver keyring.debian.org --recv-keys 0x6294BE9B

3) Verify the key fingerprints:
$ gpg --list-keys --with-fingerprint 0x6294BE9B

C) Verify the signature
$ gpg --verify SHA512SUMS.sign SHA512SUMS

D) Check the ISO
$ sha512sum -c <(grep debian-live-8.5.0-amd64-lxde-desktop.iso SHA512SUMS)
$ sha512sum debian-live-8.5.0-amd64-lxde-desktop.iso

E) Burn iso to media

F) Check media drive still has same
$ sudo fdisk -l (lookup location of burnt iso media)
$ sudo sha512sum /dev/sdb

-
Command outline (Complete with results)
$ ls
debian-8.5.0-i386-lxde-CD-1.checksum SHA512SUMS
debian-8.5.0-i386-lxde-CD-1.iso SHA512SUMS.sign
Debian8_i386_SHA256SUMS.sign
$ gpg --verify SHA512SUMS.sign SHA512SUM
S
gpg: Signature made 2016年06月05日 (週日) 23時59分09秒 CST using RSA key ID 6294BE9B
gpg: Good signature from "Debian CD signing key <debian...@lists.debian.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

$ gpg --keyserver keyring.debian.org --r
ecv-keys 0x6294BE9B
gpg: requesting key 6294BE9B from hkp server keyring.debian.org
gpg: key 6294BE9B: "Debian CD signing key <debian...@lists.debian.org>" not 
changed
gpg: Total number processed: 1
gpg: unchanged: 1

$ gpg --list-keys --with-fingerprint 0x6
294BE9B
pub 4096R/6294BE9B 2011-01-05
Key fingerprint = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
uid Debian CD signing key <debian...@lists.debian.org>
sub 4096R/11CD9819 2011-01-05

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made 2016年06月05日 (週日) 23時59分09秒 CST using RSA key ID 6294BE9B
gpg: Good signature from "Debian CD signing key <debian...@lists.debian.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B

$ sha512sum debian-8.5.0-i386-lxde-CD-1.
iso && wait && sha512sum /dev/sdb
3365649694bf623d63f37853582d3fe0f7aa774821e2533d2dc79f5d763df1751e20da98da013ccc9bd3257159362434462bd7363caff3a590e75701b81e751c

$ sudo sha512sum /dev/sdb
912ac63416f9e4cc90b10eecf08765aa3665cea3cb971865f9887b5193bdf8961cdaf7978dfbdb5a966ae03e16c6704dfd80c50eea30f9bea32b5dbd67f99747
 /dev/sdb

===
Notice how the two sha512sum numbers (local vs burnt usb) don't match!


Sincerely,
Andrew F Comly


===
===

---- Original Message 
Subject: Re: you iso's may have been hacked
Local Time: August 10, 2016 1:37 AM
UTC Time: August 10, 2016 1:37 AM
From: lim...@openmailbox.org
To: debian-user@lists.debian.org


> On 2016-08-09 20:03, phil hall wrote:
>> i have just downloaded debian gnome 8.5.0 when complete i clicked
>> check MD5 sum it listed a number that's not in your MD5sum document. I
>> have never checked an MD5sum, so don't know if this is a Mint bug or
>> you've been hacked

On 2016-08-09 20:24, limpia wrote:
> Thanks, but it would be a lot more help to know more details,
> Especially which mirror you used, what was the url to where you
> downloaded it from, ?
> Was it a amd64 image or i386 ? Was it a "Live CD image", "netinstall"
> or ?
> Thank you
Additional note, I notice that here:
https://www.debian.org/CD/faq/#verify
It says :=== "The problem with the verification of written optical
media is that some media types will possibly return more bytes than
those found in the ISO image. This trailing garbage is impossible to
avoid with CD written in TAO mode, incrementally recorded DVD-R[W],
formatted D

Re: you iso's may have been hacked

2016-08-09 Thread Doug



On 08/09/2016 08:37 PM, limpia wrote:



On 2016-08-09 20:03, phil hall wrote:

i have just downloaded debian gnome 8.5.0 when complete i clicked
check MD5 sum it listed a number that's not in your MD5sum document. I
have never checked an MD5sum, so don't know if this is a Mint bug or
you've been hacked


On 2016-08-09 20:24, limpia wrote:

 Thanks, but it would be a lot more help to know more details,
Especially which mirror you used, what was the url to where you
downloaded it from, ?
 Was it a amd64 image or i386 ? Was it a "Live CD image", 
"netinstall" or ?

 Thank you
Additional note, I notice that here: 
https://www.debian.org/CD/faq/#verify
 It says :=== "The problem with the verification of written optical 
media is that some media types will possibly return more bytes than 
those found in the ISO image. This trailing garbage is impossible to 
avoid with CD written in TAO mode, incrementally recorded DVD-R[W], 
formatted DVD-RW, DVD+RW, BD-RE, and also with USB keys. Therefore, we 
need to read exactly the same number of sectors of data from the media 
as are found in the ISO image itself; reading any more bytes from the 
media will alter the checksum result.""


 There are more details here: https://www.debian.org/CD/verify
as well, Are you sure you are checking correctly ?

Yes, of course. You can only check the md5 sum on the download. Once you 
burn it to a CD or DVD, there's no telling what the md5 sum will be.

Re: you iso's may have been hacked

2016-08-09 Thread Doug



On 08/09/2016 08:03 PM, phil hall wrote:
i have just downloaded debian gnome 8.5.0 when complete i clicked 
check MD5 sum it listed a number that's not in your MD5sum document. I 
have never checked an MD5sum, so don't know if this is a Mint bug or 
you've been hacked


If the md5 sum doesn't agree with what's posted, it most likely means a 
glitch in the data transmission. Download it again.


--doug

Re: you iso's may have been hacked

2016-08-09 Thread limpia




On 2016-08-09 20:03, phil hall wrote:

i have just downloaded debian gnome 8.5.0 when complete i clicked
check MD5 sum it listed a number that's not in your MD5sum document. I
have never checked an MD5sum, so don't know if this is a Mint bug or
you've been hacked


On 2016-08-09 20:24, limpia wrote:

 Thanks, but it would be a lot more help to know more details,
Especially which mirror you used, what was the url to where you
downloaded it from, ?
 Was it a amd64 image or i386 ? Was it a "Live CD image", "netinstall" 
or ?

 Thank you
Additional note, I notice that here: 
https://www.debian.org/CD/faq/#verify
 It says :=== "The problem with the verification of written optical 
media is that some media types will possibly return more bytes than 
those found in the ISO image. This trailing garbage is impossible to 
avoid with CD written in TAO mode, incrementally recorded DVD-R[W], 
formatted DVD-RW, DVD+RW, BD-RE, and also with USB keys. Therefore, we 
need to read exactly the same number of sectors of data from the media 
as are found in the ISO image itself; reading any more bytes from the 
media will alter the checksum result.""


 There are more details here: https://www.debian.org/CD/verify
as well, Are you sure you are checking correctly ?

Re: you iso's may have been hacked

2016-08-09 Thread limpia


On 2016-08-09 20:03, phil hall wrote:

i have just downloaded debian gnome 8.5.0 when complete i clicked
check MD5 sum it listed a number that's not in your MD5sum document. I
have never checked an MD5sum, so don't know if this is a Mint bug or
you've been hacked

 Thanks, but it would be a lot more help to know more details,
Especially which mirror you used, what was the url to where you
downloaded it from, ?
 Was it a amd64 image or i386 ? Was it a "Live CD image", "netinstall" 
or ?

 Thank you

you iso's may have been hacked

2016-08-09 Thread phil hall

i have just downloaded debian gnome 8.5.0 when complete i clicked check MD5
sum it listed a number that's not in your MD5sum document. I have never
checked an MD5sum, so don't know if this is a Mint bug or you've been hacked

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-26 Thread David Wright

On Wed 24 Feb 2016 at 10:58:56 (+0100), Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> > Well, md5 beats md4
> 
> There is something wrong in your library.

Thanks for your misplaced confidence in me. It was my timing
that wasn't rigorous enough.

Cheers,
David.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-25 Thread Thomas Schmitt

Hi,

Henrique de Moraes Holschuh wrote:
> MD5 alone can be somewhat dangerous even in benevolent environments: if the
> data sets are large enough or you are just unlucky,

The size of the data set does not matter much.
As already stated, there is the Pidgeon Hole Principle, which tells
us that a 128 bit hashsum cannot be the mapping result of all inputs
of 129 bit without having 1 exp 128 collisions. Roughly each MD5
will appear twice among the messages of 129 bit length.

Since MD5 is computed bytewise, you will get about 256 times
each possible MD5 value from the set of all 17 byte inputs.

Nevertheless the size of 128 is considered sufficient for UUID.
https://en.wikipedia.org/wiki/Universally_unique_identifier
says:

A UUID is simply a 128-bit value. [...]
The intent of UUIDs is to enable distributed systems to uniquely
identify information without significant central coordination.
In this context the word unique should be taken to mean
"practically unique" rather than "guaranteed unique".

then comes some math

https://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

"only after generating 1 billion UUIDs every second for the next 100 years,
the probability of creating just one duplicate would be about 50%."

The only "practical" objection against MD5 in this context would be
that we first have to prove its quality of uniformly distributing the
results over the space of 2 exp 128 possible values.
https://en.wikipedia.org/wiki/Hash_function#Uniformity

I am not aware that MD5 was accused of not having enough of this property.
This also yields the "practical" randomness which UUID presumes.
I understand the table in
http://michiel.buddingh.eu/distribution-of-hash-values
that MD5 has denser and sparser regions, but still is quite well uniform.

As already stated too, the Birthday Paradox hits when you create a large
collection of MD5 and add more. You have to expect the first collision
after about 2 exp 64 values. (That is about the probability to get stomped
into the earth by a 10 km asteroid until tomorrow evening. So take this
as benchmark whether you should be worried about MD5 collisions.)

I also have read a good argument in this thread about the lifetime
of contemporary hardware. It gives you few chances to process 2 exp 64
data sets of 16 bytes (256 billion gigabytes).

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-25 Thread Christian Seiler

On 02/25/2016 03:07 PM, Stefan Monnier wrote:
>> MD5 alone can be somewhat dangerous even in benevolent environments: if the
>> data sets are large enough or you are just unlucky, you are going to hit a
>> colision and corrupt-or-lose-data-on-dedup sooner or later.
> 
> [G]it doesn't seem worried about this.  Admittedly, they use sha1 rather
> than md5, so they have 160bit instead of 128bit, with a correspondingly
> lower probability of collisions, but I'd be interested to know about
> cases where md5 lead to accidental collisions.

Well, I wouldn't necessarily use that as a benchmark: git could have used
SHA2-256 from the start - it's not like SHA2 is something brand new, it
was already 4 years old when git was developed.

I haven't heard of any _accidental_ collision of either MD5 or SHA1 so
far, but I might be mistaken. (There are of course famous intentional
collisions in MD5, see .)

From a mathematical standpoint: if we assume that the values a hash may
produce are uniformly distributed and cover the entire range of possible
outputs, due to the birthday paradox accidental collisions occur every
2^(bitsize/2) inputs; for MD5 that would be 2^64, for SHA1 that would be
2^80.

Whether you can live with that is up to you.

Regards,
Christian

signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-25 Thread Stefan Monnier

>> MD5 alone can be somewhat dangerous even in benevolent environments: if the
>> data sets are large enough or you are just unlucky, you are going to hit a
>> colision and corrupt-or-lose-data-on-dedup sooner or later.
> it doesn't seem worried about this.  Admittedly, they use sha1 rather
 ^
 G


Stefan "Damn concise names!"

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-25 Thread Stefan Monnier

> MD5 alone can be somewhat dangerous even in benevolent environments: if the
> data sets are large enough or you are just unlucky, you are going to hit a
> colision and corrupt-or-lose-data-on-dedup sooner or later.

it doesn't seem worried about this.  Admittedly, they use sha1 rather
than md5, so they have 160bit instead of 128bit, with a correspondingly
lower probability of collisions, but I'd be interested to know about
cases where md5 lead to accidental collisions.


Stefan

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-25 Thread Henrique de Moraes Holschuh

On Tue, 23 Feb 2016, David Wright wrote:
> 1) I do what fdupes does, ie identify files (in a benevolent
>environment) using the MD5 signature to detect duplicate
>contents.

MD5 alone can be somewhat dangerous even in benevolent environments: if the
data sets are large enough or you are just unlucky, you are going to hit a
colision and corrupt-or-lose-data-on-dedup sooner or later.

At least use data-size + hash.  But even that won't save you for
colisions... the "full fix" is to use the hash (or size + hash) as a screen
to detect possible matches: when it matches, compare the two data-sets to
ensure they're really equal before you trigger the dedup.

I am not going to bother with the detail that you need to ensure one of the
data sets can't/didn't change under you between the comparison and the dedup
getting commited to storage.

> 2) In view of your statement that faster hashes exist, I would
>like to explore replacing my use of MD5 by such a hash.

Any wide-enough hash will do if you use it just for screening, where you
don't care for for any security properties of the hash.  And at that point,
you might as well use a wide-enough CRC (ensure it is vectorizable and get
the compiler to vectorize it!) if it proves to be faster than crypto
hashes...

-- 
  "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

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Stuart Longland

On 23/02/16 05:50, Thomas Schmitt wrote:
> But my curiosity is about whether i indirectly helped the hackers.

Technology is just that, technology.  With the exception of land mines,
it mostly is neither good nor bad itself, it's how it's used, and many
tools can be used for both.

Software is no different to this.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Christian Seiler

On 02/24/2016 01:48 PM, Nicolas George wrote:
> Le sextidi 6 ventôse, an CCXXIV, Christian Seiler a écrit :
>> Yes, I know what an HMAC is. But an HMAC is _utterly_ useless for a
>> digital signature.
> 
> Please stop commenting the finger when I try to show you the moon.

The problem is that you were being extremely vague. And if you are
not actually discussing the merits of the issue itself, but talking
about different use cases with different threat models, then you
can't come back and complain that you don't get your points across.

> You want an actual example of attack that a proper signing protocol
> prevents?

Yes, precisely. That is what I was asking for in the first place.

> 1. Alice generates harmless.iso and harmful.iso with a hash collision.
> 2. Bob generates harmless.iso.sha and signs it as harmless.iso.sha.sign.
> 3. Alice replaces harmless.iso by harmful.iso.
> 4. Eve checks the signature, the signature is valid.
> 
> Compare to:
> 
> 2. Bob signs harmless.iso as harmless.iso.sign.
> 3. Alice replaces harmless.iso by harmful.iso.
> 4. Eve checks the signature, the signature is invalid, the attack is foiled.
> 
> The principle is that a proper signing protocol needs to include in the
> hashed message parts that the attacker can not control.

Thank you. Why didn't you say so from the beginning?

Yes, under that threat model (attacker controls what is signed)
using a simple hash is problematic.

And yes, preimage attacks are harder than collision attacks (as
we've seen with MD5).

Still, I don't think that's reason enough to discourage people from
signing hash lists, because:

 1. In practical terms there's no known _feasible_ collision attack
for the SHA-2 family out there.

 2. Current software doesn't actually do what you are suggesting.
For example, the only data added before hashing by GnuPG that's
_slightly_ difficult to predict is the timestamp. (OpenPGP
doesn't actually specify a subpacket type for something like a
salt.) The rest of the stuff added to the hash function is
completely predictable. (And it's appended, so as per your
comment about MD5, for at least that hash and possibly others,
it's also useless against such an attack.)

Yes, doing it differently (e.g. also signing each individual file)
would improve the security properties, but I don't think relying on
collision attack resistance for a decent hash function is _that_
problematic. (And it's not like there weren't warning against MD5
long before the known attacks were published; that people were still
using MD5 on such a widespread basis, even after it was expected to
be broken in the not too distant future, is a different problem.)

But to be more constructive:

Let's say one creates a tool akin to sha256sum that does the
following (let's call it ssha256sum):

 - Generate two sufficiently large random numbers S1, S2
   (Let's say 128bit each.)
 - Output first line: those random numbers
 - For each file generate output similar to sha256sum, but do
   SHA256(S1 || filecontents || S2) instead

If one just signs the resulting file, in your opinion, would that
offer the same guarantees for the contents of all of the files as
signing the individual files themselves?

Regards,
Christian

signature.asc
Description: OpenPGP digital signature

OT: ownership of Mega.co.nz (was Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System)

2016-02-24 Thread Jonathan Dowland

On Thu, Feb 25, 2016 at 12:18:40AM +1100, Andrew McGlashan wrote:
> https://en.wikipedia.org/wiki/Mega_%28service%29
> 
> "In July 2015, Dotcom said he doesn't trust Mega service in a Q
> session with tech website Slashdot, claims the company had "suffered
> from a hostile takeover by a Chinese investor who is wanted in China for
> fraud" and that the New Zealand government seized this investor's shares
> and now has control of the site. Dotcom encouraged readers not to use it
> and that he plans to set up a completely open source nonprofit
> competitor. Dotcom announced on his Twitter account that he plans to
> release a detailed breakdown of Mega's status.[31][32] Mega responded
> that the authorities have not opposed or interefered with any of Mega’s
> operations.[33]"
> 
> The Q link and others available via Wikipedia

Wow. Once is unlucky. Twice seems like carelessness...

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Andrew McGlashan

On 24/02/2016 11:47 PM, Thomas Schmitt wrote:
> I wrote:
>>> ... google ... Kim Schmitz ... rofl ... i am not that curious.
> 
> Andrew McGlashan wrote:
>> Actually he doesn't run mega.nz any longer and he has said that he
>> wouldn't trust the site now due to current ownership 
> 
> Now is this what his public relations adviser told him to say ?

https://en.wikipedia.org/wiki/Mega_%28service%29

"In July 2015, Dotcom said he doesn't trust Mega service in a Q
session with tech website Slashdot, claims the company had "suffered
from a hostile takeover by a Chinese investor who is wanted in China for
fraud" and that the New Zealand government seized this investor's shares
and now has control of the site. Dotcom encouraged readers not to use it
and that he plans to set up a completely open source nonprofit
competitor. Dotcom announced on his Twitter account that he plans to
release a detailed breakdown of Mega's status.[31][32] Mega responded
that the authorities have not opposed or interefered with any of Mega’s
operations.[33]"

The Q link and others available via Wikipedia

Cheers
A.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread tomas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Feb 24, 2016 at 01:47:57PM +0100, Thomas Schmitt wrote:
> Hi,

[...]
> A large file emerges in ~/Desktop. (I am wearing my garlic necklace now,
> spraying holy water, and looking up witch signs in the Malleus Maleficarum.)

A nice and entertaining tour of bootable images. Enjoyable and instructive.
Thanks for that!

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlbNolYACgkQBcgs9XrR2kZuAACfWlzA+DEXeztqYgvP15sd69Tn
HSEAnit6UIudlaMHD4Vlbx4exmxUZJQ9
=hLoK
-END PGP SIGNATURE-

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le sextidi 6 ventôse, an CCXXIV, Christian Seiler a écrit :
> Yes, I know what an HMAC is. But an HMAC is _utterly_ useless for a
> digital signature.

Please stop commenting the finger when I try to show you the moon.

I was not saying that HMAC are useful for digital signatures, I was giving
another, simpler, example to try to get you to understand the principle.

You want an actual example of attack that a proper signing protocol
prevents? Here is one:

1. Alice generates harmless.iso and harmful.iso with a hash collision.
2. Bob generates harmless.iso.sha and signs it as harmless.iso.sha.sign.
3. Alice replaces harmless.iso by harmful.iso.
4. Eve checks the signature, the signature is valid.

Compare to:

2. Bob signs harmless.iso as harmless.iso.sign.
3. Alice replaces harmless.iso by harmful.iso.
4. Eve checks the signature, the signature is invalid, the attack is foiled.

The principle is that a proper signing protocol needs to include in the
hashed message parts that the attacker can not control.

(As a side note, IIRC, the collision attack on MD5 has the property that:
size(A) == size(B) && md5(A) == md5(B) => md5(A||C) = md5(B||C); in that
case, it would be better to include parts that the attacker can not control
before the message, not just after.)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Thomas Schmitt

Hi,

an interesting detail in advance:

It does not boot from USB stick. Too dumb for that.
>From DVD it boots only via BIOS or EFI BIOS emulation, not via
generic EFI.

I wrote:
> > ... google ... Kim Schmitz ... rofl ... i am not that curious.

Andrew McGlashan wrote:
> Actually he doesn't run mega.nz any longer and he has said that he
> wouldn't trust the site now due to current ownership 

Now is this what his public relations adviser told him to say ?

Sandboxing as good as possible ... iceweaseling with Javascript:
  https://mega.nz/#!QwY1EZKJ!GW1gLzXaOUo8sNGF-zddRLwgsfamZy7C5u0CARjaUs0

Now it wants me to download a plugin.
My gutt feeling is that i am short before winning a Darwin Award.

New approach:

  $ wget 
http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-8.3.0-amd64-xfce-desktop.iso

  $ wget 
http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/SHA512SUMS.sign

  $ wget 
http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/SHA512SUMS

  $ gpg --verify SHA512SUMS.sign SHA512SUMS
  gpg: Signature made Thu 28 Jan 2016 02:07:19 AM CET using RSA key ID 6294BE9B
  gpg: Good signature from "Debian CD signing key "
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:  There is no indication that the signature belongs to the owner.

Well, my own key is not any better. To me this step is a ritual that
is applauded by people who are better informed than me. I consider
it more a social courtesy than a personal security feature.

  $ x=$(grep debian-live-8.3.0-amd64-xfce-desktop.iso'$' SHA512SUMS)
  $ echo "$x"

1cead0dfde971e0c70145f6c908cea067ee7ee067f5ca481f076db78d99a99088be76737af4e2c9569540208d6e841f758a568ca12db077fa327e323b5da3a04
  debian-live-8.3.0-amd64-xfce-desktop.iso

  $ y=$(sha512sum debian-live-8.3.0-amd64-xfce-desktop.iso)
  $ echo $y

1cead0dfde971e0c70145f6c908cea067ee7ee067f5ca481f076db78d99a99088be76737af4e2c9569540208d6e841f758a568ca12db077fa327e323b5da3a04
  debian-live-8.3.0-amd64-xfce-desktop.iso

  $ test "$x" = "$y" && echo All is well
  All is well

To the test machine ... iceweasel warns me duely that i am about
to shoot my foot ... now the plugin is at work. I just don't see any
file emerging in ~/Downloads.
That's really scary. Like an Android phone.
A large file emerges in ~/Desktop. (I am wearing my garlic necklace now,
spraying holy water, and looking up witch signs in the Malleus Maleficarum.)

Ok. It's downloaded and md5sum says 7d590864618866c225ede058f1ba61f0.
Copying it on a DVD, not as image but as data file inside an ISO.
So it cannot hop onto innocent machines just by being put into the
DVD drive.
Back on workstation ...

They used genisoimage:

  $ xorriso -indev ...long.name...iso -pvd_info
  ...
  Volume Id: Linux Mint 17.3 Rosa 64-bit
  Volume Set Id: 
  Publisher Id : 
  Preparer Id  : 
  App Id   : GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 
E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
  System Id: LINUX
  CopyrightFile: 
  Abstract File: 
  Biblio File  : 
  Creation Time: 2016021909371600
  Cr. Time Zone: -05:00
  Modif. Time  : 2016021909371600
  Mo. Time Zone: -05:00
  Expir. Time  : 
  Eff. Time: 2016021909371600
  Ef. Time Zone: -05:00

The sequence of SUSP fields indicates that it was indeed made by
a mkisofs clone.

Now for the original

  $ wget http://...mirror.../linuxmint-17.3-cinnamon-64bit.iso
  $ md5sum linuxmint-17.3-cinnamon-64bit.iso
  e71a2aad8b58605e906dbea444dc4983

This matches the MD5 on http://www.linuxmint.com/edition.php?id=204

  $ xorriso -indev linuxmint-17.3-cinnamon-64bit.iso -pvd_info
  ...
  Volume Id: Linux Mint 17.3 Cinnamon 64-bit
  Volume Set Id: 
  Publisher Id : LINUX MINT
  Preparer Id  : LIVE-BUILD 3.0_A57-1
  App Id   : 
  System Id: 
  CopyrightFile: 
  Abstract File: 
  Biblio File  : 
  Creation Time: 2015112815084800
  Modif. Time  : 2015112815084800
  Expir. Time  : 
  Eff. Time: 

Ouch. They do not even have the same Volume Id (/dev/disk/by-label name).

The original was quite surely written by libisofs, probably under
control of xorriso. (Debian keeps my XORRISO branding in Preparer Id.)

Now for boot equipment:

  $ xorriso -hfsplus on -indev ...iso -report_el_torito plain 
-report_system_area plain
  ...
  Drive current: -indev 
'compromised-linuxmint-17.3-cinnamon-64bit-7D590864618866C225EDE058F1BA61F0.iso'
  ...
  El Torito catalog  : 160  1
  El Torito cat path : /isolinux/boot.cat
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
  El Torito boot img :   1  BIOS  y   none  0x  0x00  4 161
  El Torito img path :   1  /isolinux/isolinux.bin
  El Torito img opts :   1  boot-info-table isohybrid-suitable
  ...
  xorriso : NOTE : No System Area was loaded

That's not even an isohybrid. No EFI equipment present either.
(The criminal

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Christian Seiler

>> So a valid way to construct an OpenPGP v4 signature would be to
>> use 
>>
>> H(contents || 0x04 0x00 0x01 0x08 0x00 0x00)
>>
>> as the input for the RSA algorithm (and then pack that up in a
>> nice OpenPGP packet).
> 
> I did not have the reference of what OpenPGP does near at hand, I was more
> referring to the way hashes are used to build HMACs:
> H(K^opad || H((K^ipad) || message))
> 
> As you can see, choosing the message does not leave you enough freedom to
> exploit a collision.

Yes, I know what an HMAC is. But an HMAC is _utterly_ useless for a
digital signature. An HMAC relies on a shared _secret_ (in your
notation K) between parties to authenticate data. And I fully agree:
an HMAC is much less susceptible to hash function weaknesses than
other uses of hash functions.

The problem is: a digital signature in asymmetric cryptography cannot
(by definition) rely on a shared secret, because it must be verifiable
with publicly available information.

>> Basically: if there's a preimage attack against a hash, you are
>> able to forge OpenPGP signatures on files using that hash function
>> in the same way as you are able to break a simple hash.
> 
> Between a hash that has no known attacks and a full working preimage attack,
> there is a lot of space for limited collision attacks. Even if it does not
> apply to the simplified example I gave, a well crafted protocol will be able
> to mitigate some of these attacks. Not all, not perfectly, but still some,
> and that is better than nothing.

If you look at current cryptosystems:

 - TLS certificates (the only part of TLS that _is_ offline signed)
   use plain hashes over the data to be signed. (See RFC 3447; it
   then does more complicated things _with_ that hash, but if you
   have a collision, then you can forge a signature.)

 - OpenPGP uses a hash of the data to be signed plus a trailer
   (see my previous email), etc.

(RFC 3447 even says:
   "For the signature schemes in this document, a collision
attack is easily translated into a signature forgery."
 See )

For the integrity of an _encrypted_ message (where there is a secret)
OpenPGP does use something akin to an HMAC (they call it MDC), which
does not require the same level of resistance to collisions. But that
doesn't apply to pure signatures.

[ Original thing I responded to ]
>> If the SHA512SUMS.sign
> Stop right there. Signing a bunch of hashes is a beginner's mistake, I 
> have
> already emphasized that in this thread. It is rather sad that Debian made
> that mistake.

And I still haven't seen any reasoning why that is the case. All what
you've done is claimed that a digital signature of the contents of a
file is somehow more secure than the signature of a hash. When pressed
for explanations, you simply claimed:

>>> The protocol used for cryptographic signatures builds and encrypts the hash
>>> in a way that protects from most attacks against the hash algorithm itself.

When asked for specifics, you mentioned unrelated examples such as
scrambling passwords and HMACs, both of which do not apply to digital
signatures such as made by Debian. Don't get me wrong, I agree that
simply using a hash is sometimes the wrong thing to do, and your
reasoning applies to the examples you provided, but not the use case
you were initially referring to.

But again: you claimed that Debian is making a mistake with the way
APT handles signatures, because it's similar to SHA256SUMS.asc. I
still haven't heard any explanation as to why what is a mistake - and
all you've brought up are examples as to why for _other_ use cases
there are good protocol designs that don't rely so heavily on hash
function properties.

What good design is there for offline asymmetric digital signatures?
A keyword would suffice, as long as it's specific enough.

But even if I grant you that there are algorithms for signatures out
there that don't suffer from hash collisions: it's one thing to point
out that using SHA256SUMS.asc relies on the collision resistance of
SHA256, it's another to say that using a scheme like that is a mistake.
At the moment SHA256 is considered to be collision resistant for
crypto purposes by the broader community, and while it's objectively
better to have something that doesn't rely on collision resistance (if
all else is equal), it does not mean that signing a list of hashes is
inherently problematic at the moment, as long as the hash function
you're using is sufficiently strong. So instead of using using
derisive language such as "beginner's mistake" (which is laughable,
because I wouldn't call the people designing modern crypto we all rely
on beginners), you could be much more specific and say "here, look,
there's a much better solution out there called X and it will improve
what you're doing". That would be far more constructive. Just
saying...

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Richard Hector

On 24/02/16 22:50, Nicolas George wrote:
> Le sextidi 6 ventôse, an CCXXIV, Richard Hector a écrit :
>> Fair enough. Got a link to someone else's explanation?
> 
> Sorry, I do not. But I gave a rather lengthy explanation myself in
> the part you trimmed.

Oh, ok. I assumed from your comment about not wanting to explain that
there was more that you weren't explaining. That and I'm a bit short
on sleep :-) I'll have another look later.

Richard

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> Well, md5 beats md4

There is something wrong in your library.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Christian Seiler a écrit :
> But if you say what Debian is doing is a mistake, then this _is_ what
> you are talking about.

I am quite sure of what I am talking about and what I am not talking about.

> This is decisively not true when we are talking about signing files. If
> you look at RFC 4880 [1], if you sign a normal file ("binary document",
> type 0x00), what is signed with the asymmetric algorithm is [2]:
> 
> asym_input = H(contents || trailer)
> 
> In OpenPGP v4, the trailer is given by [3]
> 
> trailer = 0x04 || sigtype || pkalg || hashalg || hsplen || hspdata
> sigtype = 0x00 (binary document)
> pkgalg  = public key algorithm, e.g. 0x01 (RSA)
> hashalg = hash algorithm, e.g. 0x08 (SHA256)
> 
> hsplen: two octets denoting the length of hspdata (may be 0)
> hspdata: subpackets, containing e.g. signature date and time
> 
> So a valid way to construct an OpenPGP v4 signature would be to
> use 
> 
> H(contents || 0x04 0x00 0x01 0x08 0x00 0x00)
> 
> as the input for the RSA algorithm (and then pack that up in a
> nice OpenPGP packet).

I did not have the reference of what OpenPGP does near at hand, I was more
referring to the way hashes are used to build HMACs:
H(K^opad || H((K^ipad) || message))

As you can see, choosing the message does not leave you enough freedom to
exploit a collision.

> Furthermore, what you are saying doesn't make much sense: even if
> you add some random nonce (maybe in a subpacket, which at least
> GnuPG doesn't appear to do), what does that protect against?
> 
> If you have a signature by a given key, and you have a feasible
> preimage attack against the hash algorithm used in that specific
> signature, you only need to find a preimage collision against your
> chosen file contents concatenated with the trailer used in that
> specific signature. Since _any_ preimage attack needs to deal with
> prefixes and suffixes anyway (file formats that are processed have
> certain things that need to exist in the right places for programs
> processing these files to accept them), I don't see how that makes
> this any more difficult.
> 
> Basically: if there's a preimage attack against a hash, you are
> able to forge OpenPGP signatures on files using that hash function
> in the same way as you are able to break a simple hash.

Between a hash that has no known attacks and a full working preimage attack,
there is a lot of space for limited collision attacks. Even if it does not
apply to the simplified example I gave, a well crafted protocol will be able
to mitigate some of these attacks. Not all, not perfectly, but still some,
and that is better than nothing.

> Actually, scrambling passwords is more complicated than what you
> describe

I did not describe how to scramble passwords, I just explained why one side
of the process was necessary. The requirement of expensive computations
exists too, but it is irrelevant for the current discussion.


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le sextidi 6 ventôse, an CCXXIV, Richard Hector a écrit :
> Fair enough. Got a link to someone else's explanation?

Sorry, I do not. But I gave a rather lengthy explanation myself in the part
you trimmed.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Richard Hector

On 24/02/16 07:52, Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, Christian Seiler a écrit :
>> > You have _emphasized_ it, but you haven't _explained_ it, nor provided
>> > any search term one could use to look up an explanation for it.
> Explaining takes time, I do not want to do it if nobody will read it.
> 

Fair enough. Got a link to someone else's explanation?

Richard

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Andrew McGlashan

On 23/02/2016 10:02 PM, Thomas Schmitt wrote:
> Hi,
> 
> Nicolas George wrote:
>> Of course, that does not mean MD5 and SHA-1 should be used nowadays. New
>> theoretical attacks are found, keeping using hashes with known weaknesses is
>> stupid.
> 
> The ISO checksums are provided more for transport verification than
> for the fight against intentional mainpulation.
> Signing the hash lists by PGP still seems a bit weak as protection.

Sigs can help, but then you need to know that you have the correct
/fingerprint/ and that you trust it.  Methods to check trust are
described fairly well at the Tails website (of the Tor project).

They have sigs from Debian devs and others, if you trust those devs,
then you are a long way towards trusting the fingerprint and then you
should be able to trust the signature.

https://tails.boum.org/doc/get/trusting_tails_signing_key/index.en.html

So, if the keys are done right and signing is done with trusted sigs,
well... you should be fine with testing the sig properly.
'
Cheers
A.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-24 Thread Andrew McGlashan

On 23/02/2016 9:50 AM, Thomas Schmitt wrote:
> Hi,
> 
> Sven Hartge wrote:
>> You cannot wget a mega.nz URL. You have to use a Javascript-enabled
>> Browser to get the file.
> 
> Shall i really enable insecure Javascript to download a malicious ISO ?
> 
> ... google ... Kim Schmitz ... rofl ... i am not that curious.

Actually he doesn't run mega.nz any longer and he has said that he
wouldn't trust the site now due to current ownership (at least that's
what I remember without a search.

Cheers
A.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread David Wright

On Tue 23 Feb 2016 at 16:58:38 (+0100), Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> > 1) I do what fdupes does, ie identify files (in a benevolent
> >environment) using the MD5 signature to detect duplicate
> >contents.
> 
> You did not specify the average size of files nor how sure you want to be.

Just the usual mix of normal user files. Nothing specialised here.

> If the files are large, I would suggest to use a sparse hash function, i.e.
> a hash function that only reads small parts of the file, and do a full
> comparison or compute a strong hash only for files that have a collision on
> that.

After eliminating uniquely-sized files, I do check the first chunk of
files with identical lengths before I hash them. I think the following
methods are the only ones easily available.

> > >>> hashlib.algorithms_guaranteed
> > {'md5', 'sha1', 'sha224', 'sha512', 'sha384', 'sha256'}
> > >>> hashlib.algorithms_available
> > {'MD4', 'md5', 'md4', 'sha1', 'MD5', 'dsaWithSHA', 'whirlpool', 'sha',
> > 'SHA512', 'SHA256', 'ripemd160', 'sha512', 'SHA384', 'sha384',
> > 'dsaEncryption', 'RIPEMD160', 'sha256', 'SHA224', 'SHA1',
> > 'ecdsa-with-SHA1', 'DSA', 'SHA', 'sha224', 'DSA-SHA'}
> 
> These are all cryptographic hash functions: too strong for a preliminary
> test, insufficient for absolute certainty.

Good enough for me (apart from the specially-crafted pair of letters
from Julius Caesar).

> Still, you can easily benchmark.

Well, md5 beats md4 and sha1, so I guess I'll stick with that for the
time being.

Cheers,
David.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread Christian Seiler

On 02/23/2016 07:52 PM, Nicolas George wrote:
> What you quote is about signing a summary of files at once versus signing
> each file individually. This is not what I was talking about. What I was
> talking about was signing the file contents itself versus signing the hash
> of the file.

But if you say what Debian is doing is a mistake, then this _is_ what
you are talking about.

> The protocol used for cryptographic signatures builds and encrypts the hash
> in a way that protects from most attacks against the hash algorithm itself.
> For example, even though we know how to craft MD5 collisions easily, these
> collisions can not be used to make fake signatures even with protocols that
> use MD5, because these protocols make sure that variable octets are inserted
> in front of the payload.

This is decisively not true when we are talking about signing files. If
you look at RFC 4880 [1], if you sign a normal file ("binary document",
type 0x00), what is signed with the asymmetric algorithm is [2]:

asym_input = H(contents || trailer)

In OpenPGP v4, the trailer is given by [3]

trailer = 0x04 || sigtype || pkalg || hashalg || hsplen || hspdata
sigtype = 0x00 (binary document)
pkgalg  = public key algorithm, e.g. 0x01 (RSA)
hashalg = hash algorithm, e.g. 0x08 (SHA256)

hsplen: two octets denoting the length of hspdata (may be 0)
hspdata: subpackets, containing e.g. signature date and time

So a valid way to construct an OpenPGP v4 signature would be to
use 

H(contents || 0x04 0x00 0x01 0x08 0x00 0x00)

as the input for the RSA algorithm (and then pack that up in a
nice OpenPGP packet).

Furthermore, what you are saying doesn't make much sense: even if
you add some random nonce (maybe in a subpacket, which at least
GnuPG doesn't appear to do), what does that protect against?

If you have a signature by a given key, and you have a feasible
preimage attack against the hash algorithm used in that specific
signature, you only need to find a preimage collision against your
chosen file contents concatenated with the trailer used in that
specific signature. Since _any_ preimage attack needs to deal with
prefixes and suffixes anyway (file formats that are processed have
certain things that need to exist in the right places for programs
processing these files to accept them), I don't see how that makes
this any more difficult.

Basically: if there's a preimage attack against a hash, you are
able to forge OpenPGP signatures on files using that hash function
in the same way as you are able to break a simple hash.

The _only_ way I can see that a signed simple hash is less secure
than a direct signature is that you can play around with padding,
which will reduce the effort for preimage attacks. For this reason
Debian also encodes (and checks) the length of the files in the
archive summary files.

> The same goes for other uses of crypto primitives. Consider scrambled
> passwords for example? Do you agree that just hashing a password is a
> beginner's mistake? A correct protocol requires a random salt: that way,
> password can be checked individually, but not brute-forced collectively; if
> attackers gets hold of a database of millions of scrambled passowrds, with a
> proper salt they have to build a dictionary attack for each password,
> without a salt they can attack the whole database at once.

Actually, scrambling passwords is more complicated than what you
describe, and simply salting them is still not sufficient, you need
to actually make it hard for brute-forcing (because the entropy of
a password is typically low), so you actually want something that's
computationally expensive and not easily done on GPUs an such, e.g.
scrypt or bcrypt.

> All this is quite orthogonal to the issues you quoted, which were about
> signing not only the files' individual contents but also the files' metadata
> and the global information about what files are in the collection. Signing
> the hash file protects against that but is wide open for collision attacks.
> A proper protocol can protect both.

OpenPGPv4 can't protect against hash collisions (see my reasoning
above) - and I seriously doubt you could construct a mechanism that
works offline which does protect against hash collisions.

There are _other_ use cases where collision resistance of a hash is
not that important; preimage attacks are still quite expensive, so
attacking HMACs with session keys for a live TLS session (as long
as rekeying happens often enough) is probably not feasible even for
weaker hash functions. But you were saying that Debian's use of
hash lists is a mistake, and I still don't see how that is the case.

Regards,
Christian

[1] http://tools.ietf.org/html/rfc4880
[2] http://tools.ietf.org/html/rfc4880#section-5.2.4
"For binary document signatures (type 0x00), the document data
is hashed directly." [...] "Once the data body is hashed, then
a trailer is hashed."
[3] http://tools.ietf.org/html/rfc4880#section-5.2.4
"A V4 signature hashes the

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Christian Seiler a écrit :
> You have _emphasized_ it, but you haven't _explained_ it, nor provided
> any search term one could use to look up an explanation for it.

Explaining takes time, I do not want to do it if nobody will read it.

> Why is what Debian does a mistake? Debian stores both the hash value
> and the file size in the Packages, Sources and Release files. (Packages
> references e.g. the .deb packages, Release references the "Packages"
> file and Release itself is signed.) Assuming that there's no feasible
> preimage attack against the hash function, and the file containing the
> hashes + sizes is signed via GnuPG, how is that problematic, as long as
> you check everything along the way?
> 
> Also note that the Tor project (and I believe they do know something
> about security) uses hash lists for reproducibility:
> https://www.torproject.org/docs/verifying-signatures.html.en
> (To be fair, they also sign each file individually, but the
> instructions to verify builds w.r.t. reproducibility specifically
> talk about hash lists.)
> 
> Also, note:
> http://crypto.stackexchange.com/questions/24224/signing-files-vs-signing-file-hashes
> The person writing the top answer to that question has his own blog
> about cryptography: https://www.chosenplaintext.ca/
> 
> Since what you are talking about is apparently non-obvious to people
> who do crypto for a living, your characterization of _beginner's_
> mistake is definitely wrong. If it's a mistake, it's apparently a
> highly non-trivial one.

What you quote is about signing a summary of files at once versus signing
each file individually. This is not what I was talking about. What I was
talking about was signing the file contents itself versus signing the hash
of the file.

Do not get things wrong: signing a file involves a hash of that file,
because asymmetric ciphers, the keystone for building signing protocols, are
way too slow to be used on large files, and also for a few other
considerations. But the cipher is not simply applied to the hash.

If you build a wall, you do not just stack stones together, you fit them so
that strengths of some stones will compensate weaknesses of others.

The same goes for cryptography. If you just stack the cryptographic
primitives together, the resulting protocol compounds the weaknesses of its
components. In particular, any collision in the hash function is directly a
fake signature.

I suppose it would be acceptable, but the crux is: we know how to do better
without extra computational costs.

Of course, if the hash function and the asymmetric cipher both are flawless,
then their simple stacking would be secure. But flaws are discovered in
algorithms frequently.

The protocol used for cryptographic signatures builds and encrypts the hash
in a way that protects from most attacks against the hash algorithm itself.
For example, even though we know how to craft MD5 collisions easily, these
collisions can not be used to make fake signatures even with protocols that
use MD5, because these protocols make sure that variable octets are inserted
in front of the payload.

The core of the issue is that hash functions have properties that are not
needed in a signing protocol. More precisely, the same hash function applied
to the same file yields always the same result, of course. But we do not
need that in a signing protocol. Quite the contrary, in fact. All we need is
to be able to check the signature, but generating a different signature each
time can be considered a plus in many situations.

The same goes for other uses of crypto primitives. Consider scrambled
passwords for example? Do you agree that just hashing a password is a
beginner's mistake? A correct protocol requires a random salt: that way,
password can be checked individually, but not brute-forced collectively; if
attackers gets hold of a database of millions of scrambled passowrds, with a
proper salt they have to build a dictionary attack for each password,
without a salt they can attack the whole database at once.

All this is quite orthogonal to the issues you quoted, which were about
signing not only the files' individual contents but also the files' metadata
and the global information about what files are in the collection. Signing
the hash file protects against that but is wide open for collision attacks.
A proper protocol can protect both.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread Christian Seiler

On 02/23/2016 04:49 PM, Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
>> If the SHA512SUMS.sign
> 
> Stop right there. Signing a bunch of hashes is a beginner's mistake, I have
> already emphasized that in this thread.

You have _emphasized_ it, but you haven't _explained_ it, nor provided
any search term one could use to look up an explanation for it.

> It is rather sad that Debian made that mistake.

Why is what Debian does a mistake? Debian stores both the hash value
and the file size in the Packages, Sources and Release files. (Packages
references e.g. the .deb packages, Release references the "Packages"
file and Release itself is signed.) Assuming that there's no feasible
preimage attack against the hash function, and the file containing the
hashes + sizes is signed via GnuPG, how is that problematic, as long as
you check everything along the way?

Also note that the Tor project (and I believe they do know something
about security) uses hash lists for reproducibility:
https://www.torproject.org/docs/verifying-signatures.html.en
(To be fair, they also sign each file individually, but the
instructions to verify builds w.r.t. reproducibility specifically
talk about hash lists.)

Also, note:
http://crypto.stackexchange.com/questions/24224/signing-files-vs-signing-file-hashes
The person writing the top answer to that question has his own blog
about cryptography: https://www.chosenplaintext.ca/

Since what you are talking about is apparently non-obvious to people
who do crypto for a living, your characterization of _beginner's_
mistake is definitely wrong. If it's a mistake, it's apparently a
highly non-trivial one.

Therefore, could you please provide some reasoning for your claim
that what Debian does is a mistake?

Regards,
Christian

signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> You have unsurpassable objections against variants which might not
> much weaken the strength of PGP ?
> Not even willing to consider the constraints of such variants ?

I have no idea what you are trying to express.

> Despite leading developers making "beginner's mistakes" ?

Packaging software and cryptography are two completely different tasks that
requires completely different skills.

> Please google "fdupes".

Please write self-sufficient messages.

> 200 GB ?

What, "200 GB"? Are you always hashing your whole drive at once?

> Does this advise count as pot-kettle-black incident ?
> After all you make assumptions about the files' content similarities
> or the lack thereof.

Once again, I have no idea what you are trying to express.


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread arian

> The collisions are not known, and very unlikely, but "absolute" means
> absolute, not "very likely".

from the way you stated:
> These are all cryptographic hash functions: too strong for a preliminary
> test, insufficient for absolute certainty.

I understood you suggest there is a relevant level of uncertainty, one that 
will bite someone and should therefore be avoided (for the purpose of comparing 
files from sources that they trust to hold their data for that matter)



signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, arian a écrit :
> where do you get that these are "insufficient for absolute certainty"?
> (beside maybe md4)
> there are no known collisions in sha1 and better, and even md4's preimage
> attack has complexity 2^102. [1,2]

There are collisions for SHA1 as soon as the files are larger than 20 bytes.
The same applies to SHA-2 with the corresponding size.

The collisions are not known, and very unlikely, but "absolute" means
absolute, not "very likely".

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Nicolas George wrote:
> Signing a bunch of hashes is a beginner's mistake,

You have unsurpassable objections against variants which might not
much weaken the strength of PGP ?
Not even willing to consider the constraints of such variants ?

I assume this was discussed among DDs and they weighed their options.

> I rely on Debian packagers to be on the watch.

Despite leading developers making "beginner's mistakes" ?

Well, Debian allows me to package my own upstream.
My sponsor looks at the Debian specific aspects of packaging,
not at my source code. (Dominique, please correct me if i'm wrong.)

There are dozens of package updates every day. Have a look at the
"Needs-Build" list of the SH4 ghost fleet:
  https://buildd.debian.org/status/architecture.php?a=sh4=sid
(Yamato and Tirpitz are on cruise, currently. Huso is stuck in pack ice.
 First tries of packages with known short build times seem the be
 preferred. libburn passes after only a few hours.)

Given the fact how hard it is to find a dedicated DD or DM for new
upstream packages, i cannot imagine that many such packages get a
special security audit by Debian.
Look at the archives of debian-mentors mailing list. The heroes there
criticise many oddities and software release sins. But in the 5 months
since i am watching, i saw not a single objection because of upstream
source code flaws. (And there are many, i am sure. Just count mine.)

> I blame you for giving advice without knowing the problem.

Please google "fdupes".

> Ever heard of cache?

200 GB ? I only have 16 GB RAM.

> > (The polynomials should at least not be multiples of each other.)

> The polynomials must be irreducible to yield a correct CRC32.
> That rules out them being multiples of each other.

So you found a widening of my "at least".
(May i criticise in reply the fuzzyness of the term "correct" ?)

> If the files are large, I would suggest to use a sparse hash function,

Does this advise count as pot-kettle-black incident ?
After all you make assumptions about the files' content similarities
or the lack thereof.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread arian

> and even md4's preimage attack has complexity 2^102. [1,2]

sorry, forgot the quotes:
[1] https://en.wikipedia.org/wiki/Preimage_attack
[2] https://en.wikipedia.org/wiki/MD4#Security




signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread arian


> These are all cryptographic hash functions: too strong for a preliminary
> test, insufficient for absolute certainty.

where do you get that these are "insufficient for absolute certainty"? (beside 
maybe md4)
there are no known collisions in sha1 and better, and even md4's preimage 
attack has complexity 2^102. [1,2]

OTOH harddrive manufacturers state MTBF of around 500'000 h, and that's just a 
fraction of the error sources you have. HDDs read at around 150 MB/s, so in 
those 500'000h they read:
5e5 h*3600 s/h*150e6 B/s *8 b/B = 2.16e18 = 2^55
- so from that you have 2^47 higher probability of random errors over the worst 
algorithm's failure. That's probably around the number of bits of your personal 
storage. Stated differently: until hash functions flip one bit of your storage 
wrong, storage itself has eaten it all.

of course, those estimates are off the real (unknown) numbers, you probably 
have unknown attacks on any hash, which may be far better than 2^102. But how 
many of 1960s harddrives and computer around it are still running and have 
produced only one wrong bit in their lifetime? MTBFs are far off too.



signature.asc
Description: OpenPGP digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Seeker a écrit :
> If you take security out of the equation, simple true or false.
> 
> 1. A corrupted download is better able to be detected when using MD5 than it
> is with CRC32.
> 
> 2. A corrupted download is better able to be detected when using SHA than it
> is with MD5.

Obviously, for random alterations, the larger the hash, the less likely a
corruption is.

> If I have extra reason to suspect corruption might occur I definitely want
> to use the most capable option for detecting that.

Then I suggest you download your file a thousand times and compare them, and
redo the whole downloads if any of the copies is different from the others.

Impractical? Yes, of course. The problem lies with your statement of the
situation: you use a single metric, the odds of a corrupted download,
instead of at least two, including the cost of the checks.


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread Seeker




On 2/23/2016 3:08 AM, Nicolas George wrote:

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :

The ISO checksums are provided more for transport verification than
for the fight against intentional mainpulation.

If that were true, CRC32 would be enough.



Is that a 'Law of averages' thing?

I'll leave the security stuff to others.

If you take security out of the equation, simple true or false.

1. A corrupted download is better able to be detected when using MD5 
than it is with CRC32.


2. A corrupted download is better able to be detected when using SHA 
than it is with MD5.


I don't typically have an issue with corrupt downloads, but still there 
are those days where
something is a bit flaky somewhere in the chain and downloads show 
intermittent periods
of inactivity, sometimes failing and having to be resumed or restarted, 
sometimes multiple

times to get a completed download.

Murphy's law 'Anything that can happen will happen', it's possible for a 
download with
random corruption to pass verification, it will happen eventually. The 
higher the risk
of corruption, the higher the odds are, however small those odds might 
be, that you get a

corrupted download that passes verification.

If I have extra reason to suspect corruption might occur I definitely 
want to use the most
capable option for detecting that. Just because that is not generally 
that case doesn't mean

I generally want to settle for a less capable option.

Later, Seeker

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> 1) I do what fdupes does, ie identify files (in a benevolent
>environment) using the MD5 signature to detect duplicate
>contents.

You did not specify the average size of files nor how sure you want to be.

If the files are large, I would suggest to use a sparse hash function, i.e.
a hash function that only reads small parts of the file, and do a full
comparison or compute a strong hash only for files that have a collision on
that.

> >>> hashlib.algorithms_guaranteed
> {'md5', 'sha1', 'sha224', 'sha512', 'sha384', 'sha256'}
> >>> hashlib.algorithms_available
> {'MD4', 'md5', 'md4', 'sha1', 'MD5', 'dsaWithSHA', 'whirlpool', 'sha',
> 'SHA512', 'SHA256', 'ripemd160', 'sha512', 'SHA384', 'sha384',
> 'dsaEncryption', 'RIPEMD160', 'sha256', 'SHA224', 'SHA1',
> 'ecdsa-with-SHA1', 'DSA', 'SHA', 'sha224', 'DSA-SHA'}

These are all cryptographic hash functions: too strong for a preliminary
test, insufficient for absolute certainty.

Still, you can easily benchmark.


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread David Wright

On Tue 23 Feb 2016 at 16:04:37 (+0100), Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> > Any faster ones that you recommend from the lists below? (I've rolled
> > my own implementation of fdupes (which uses MD5) in python.)
> 
> Nobody can recommend anything without knowing the intended use.

I don't understand. The intended use is in the previous line:

"my own implementation of fdupes (which uses MD5) in python"

and also in Thomas's statement:

"we want to use it for identifying files in benevolent environments"

(which you snipped).

So to summarise:

1) I do what fdupes does, ie identify files (in a benevolent
   environment) using the MD5 signature to detect duplicate
   contents.
2) In view of your statement that faster hashes exist, I would
   like to explore replacing my use of MD5 by such a hash.
3) My python implementation has the following hashes in its own
   library, either "available on this platform" or "guaranteed
   on all python platforms". Using one of these makes altering
   my program easier than having to find out how to call an
   external hashing program (and the calls might slow things
   back down again).
4) As you're far more familiar with hashing than I am (and
   many people here), would you have any recommendations from
   these two lists?

Python 3.4.2 (default, Oct  8 2014, 13:14:40)
...
>>> hashlib.algorithms_guaranteed
{'md5', 'sha1', 'sha224', 'sha512', 'sha384', 'sha256'}
>>> hashlib.algorithms_available
{'MD4', 'md5', 'md4', 'sha1', 'MD5', 'dsaWithSHA', 'whirlpool', 'sha',
'SHA512', 'SHA256', 'ripemd160', 'sha512', 'SHA384', 'sha384',
'dsaEncryption', 'RIPEMD160', 'sha256', 'SHA224', 'SHA1',
'ecdsa-with-SHA1', 'DSA', 'SHA', 'sha224', 'DSA-SHA'}
>>> 

I hope that explains things better than my previous attempt.

Cheers,
David.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> Only as far as use cases for Debian ISO image hashs are concerned.
> No hash collisions among all Debian ISOs (or better all ISOs in the
> world) is a valuable property.

??? I have no idea what you are talking about.

> If the SHA512SUMS.sign

Stop right there. Signing a bunch of hashes is a beginner's mistake, I have
already emphasized that in this thread. It is rather sad that Debian made
that mistake.

> So the strength of PGP relative to the strength of the used
> combined checksums does matter.

Not if the signature is done correctly, on the data itself and not a
derivative.

> But as said previously, the biggest danger is in evil package sources.

This is completely unrelated. And as a side note, I rely on Debian packagers
to be on the watch.

> MD5 is much less prone than are us upstreamers.
> (What shall i do if the Bundesnachrichtendienst rings my doorbell,
> has the Verfassungsschutz in tow, plus a bailiff and two police
> officers, while an armed drone is cycling over my house ?)

???

> As long as no intentional covert manipulations are to fear, MD5
> will suffice for any reasonable degree of certainty.

I blame you for giving advice without knowing the problem.

> On my machines of the last 10 years, MD5 computation was always
> faster than hard disk reading.

Ever heard of cache?

> As for CRC, a skilled choice of two different divisor
> polynomials is supposed to yield two independent 32 bit sums.
> (The polynomials should at least not be multiples of each other.)

The polynomials must be irreducible to yield a correct CRC32. That rules out
them being multiples of each other.


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Nicolas George wrote:
> > You are changing the terms of the problem at each messages,

Only as far as use cases for Debian ISO image hashs are concerned.
No hash collisions among all Debian ISOs (or better all ISOs in the
world) is a valuable property.

i wrote:
> > > I could imagine that PGP is easier to surpass than that.

> > It is not a matter of surpassing anything.

There is no use in converting the frontside of the house into
a fortress while having a backdoor made of cardboard.

If the SHA512SUMS.sign file can be hacked, then the SHA512 sums
are not trustworthy any more.
So the strength of PGP relative to the strength of the used
combined checksums does matter.

But as said previously, the biggest danger is in evil package sources.
MD5 is much less prone than are us upstreamers.
(What shall i do if the Bundesnachrichtendienst rings my doorbell,
has the Verfassungsschutz in tow, plus a bailiff and two police
officers, while an armed drone is cycling over my house ?)

David Wright wrote:
> But it's raised an issue that interests me...
> ...
> (I've rolled my own implementation of fdupes (which uses MD5) in python.)

As long as no intentional covert manipulations are to fear, MD5
will suffice for any reasonable degree of certainty.
(Unless you regularly prepare for the asteroid impact and thus
 can be considered as sufficiently paranoid.)

On my machines of the last 10 years, MD5 computation was always
faster than hard disk reading. So a faster algorithm for my
backup checksums would not speed up the backup preparations.

As for CRC, a skilled choice of two different divisor
polynomials is supposed to yield two independent 32 bit sums.
(The polynomials should at least not be multiples of each other.)

https://en.wikipedia.org/wiki/Polynomial_representations_of_cyclic_redundancy_checks
I'd expect that those would be computed faster than MD5, if
you use a table based implementation.
64 bits with targeted comparison and 32 bits with search over
a larger set should suffice for many purposes.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, David Wright a écrit :
> Any faster ones that you recommend from the lists below? (I've rolled
> my own implementation of fdupes (which uses MD5) in python.)

Nobody can recommend anything without knowing the intended use.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread David Wright

On Tue 23 Feb 2016 at 13:15:38 (+0100), Nicolas George wrote:
> Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> > i wrote:
> > > > The ISO checksums are provided more for transport verification than
> > > > for the fight against intentional mainpulation.
> 
> > Nicolas George wrote:
> > > If that were true, CRC32 would be enough.
> 
> > For detecting most glitches, yes.
> > But not if we want to use it for identifying files in benevolent
> > environments.
> 
> You are changing the terms of the problem at each messages, it does not make
> for a constructive discussion.

But it's raised an issue that interests me...

> I am sure that you can come up with enough far-fetched conditions to build a
> situation where MD5 would be the best choice, but this is not relevant for
> real world situations.
> 
> For real world situations, to protect against hostile tampering MD5 is
> broken, and to protect against accidental tampering, faster hashes exist.

Any faster ones that you recommend from the lists below? (I've rolled
my own implementation of fdupes (which uses MD5) in python.)

Python 3.4.2 (default, Oct  8 2014, 13:14:40) 
...
>>> hashlib.algorithms_guaranteed
{'md5', 'sha1', 'sha224', 'sha512', 'sha384', 'sha256'}
>>> hashlib.algorithms_available
{'MD4', 'md5', 'md4', 'sha1', 'MD5', 'dsaWithSHA', 'whirlpool', 'sha',
'SHA512', 'SHA256', 'ripemd160', 'sha512', 'SHA384', 'sha384',
'dsaEncryption', 'RIPEMD160', 'sha256', 'SHA224', 'SHA1',
'ecdsa-with-SHA1', 'DSA', 'SHA', 'sha224', 'DSA-SHA'}
>>> 

Cheers,
David.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> i have to revoke some of my criticism towards Debian's signed
> hash value lists.
> Together, MD5, SHA1, SHA256, and SHA512 provide up to 132 bytes of
> uniqueness (assumed that they have no systematic correlations).

This is irrelevant. For brute-force attacks, even MD5's 128 bits are still
enough. Even with future-proofing against computing speedups and a
reasonable amount of theoretical short-cuts, SHA256 is still plenty enough
all by itself. Beyond that, speculating on unknown attacks is always
useless. And of course, all the hype nowadays is about quantum-resistant
algorithms.

> I could imagine that PGP is easier to surpass than that.

It is not a matter of surpassing anything. Cryptographic signatures protect
against all the same attacks as hashes, plus a whole bunch of new attacks.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> i wrote:
> > > The ISO checksums are provided more for transport verification than
> > > for the fight against intentional mainpulation.

> Nicolas George wrote:
> > If that were true, CRC32 would be enough.

> For detecting most glitches, yes.
> But not if we want to use it for identifying files in benevolent
> environments.

You are changing the terms of the problem at each messages, it does not make
for a constructive discussion.

I am sure that you can come up with enough far-fetched conditions to build a
situation where MD5 would be the best choice, but this is not relevant for
real world situations.

For real world situations, to protect against hostile tampering MD5 is
broken, and to protect against accidental tampering, faster hashes exist.

signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

i wrote:
> > The ISO checksums are provided more for transport verification than
> > for the fight against intentional mainpulation.

Nicolas George wrote:
> If that were true, CRC32 would be enough.

For detecting most glitches, yes.
But not if we want to use it for identifying files in benevolent
environments.

The birthday paradox predicts that CRC32 will produce the first
collision after square root of 32 bit, i.e. 16 bit = 65536 tries.

MD5 gets square rooted to 64 bit, which gives a collision roughly
the same probability as that a 10 km asteroid hits you (not me)
directly within a day. Assumed that such a thing happens every
100 million years.

(And well, who would respect a person that divides polynomials on
a Galois field.)

> Signing hashes will get you a spanking from any cryptographer.

I sign my release tarballs by a gpg command which i really don't
understand, except that Karl Berry of FSF teached me to use it for
GNU uploads.
(How many bits worth is Karl's reputation and my illusion that it
was him who wrote to me ?)

I wonder whether there are performance reasons why only the hashs
of Debian ISOs are PGP signed.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread Andrew M.A. Cater

On Tue, Feb 23, 2016 at 12:02:50PM +0100, Thomas Schmitt wrote:
> Hi,
> 
> Nicolas George wrote:
> > Of course, that does not mean MD5 and SHA-1 should be used nowadays. New
> > theoretical attacks are found, keeping using hashes with known weaknesses is
> > stupid.
> 
> The ISO checksums are provided more for transport verification than
> for the fight against intentional mainpulation.
> Signing the hash lists by PGP still seems a bit weak as protection.
> 
> But well, if Debian armors its ISOs, then it would have to scrutinize
> the source of its packages, too.
> 

The reproducible builds work now going on will make this much easier.
Anybody should be able to reproduce _exactly_ what was generated, anywhere
and with a very high confidence in every stage.

This may not be immediately evident for the current release - though more
and more of it is becoming reproducible - but will be very evident for Stretch
- Debian 9 - when released as stable.

> Most important seems a permanent supervision of the web site content
> from not publicly known client machines. Hash sums may be manipulated.
> But the whole content of an ISO is either original or not. Easy to spot.
> 
> 

Not quite so obvious if the attacker(s) have had significant time to build
and modify individual packages and get the changes pushed in - but see above.

> Have a nice day :)
> 
> Thomas

Likewise :)

AndyC

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

i have to revoke some of my criticism towards Debian's signed
hash value lists.
Together, MD5, SHA1, SHA256, and SHA512 provide up to 132 bytes of
uniqueness (assumed that they have no systematic correlations).
I could imagine that PGP is easier to surpass than that.

Well, according to wikipedia, MD5 is meanwhile only a barrier tape
which distinguishes curious bystanders from intentional attackers.


Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Thomas Schmitt a écrit :
> The ISO checksums are provided more for transport verification than
> for the fight against intentional mainpulation.

If that were true, CRC32 would be enough.

> Signing the hash lists by PGP still seems a bit weak as protection.

Signing hashes will get you a spanking from any cryptographer.
Cryptographic signatures must be applied on the file itself; it works
internally by signing a hash of the file, but the hash is done in a way that
prevents most attacks even with weak hashes.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread jdd


Le 23/02/2016 12:02, Thomas Schmitt a écrit :


Most important seems a permanent supervision of the web site content
from not publicly known client machines.


if I followed right this, there was a redirect to an external site. How 
can this be possible?


html links is the first thing spam uses

jdd

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Nicolas George wrote:
> Of course, that does not mean MD5 and SHA-1 should be used nowadays. New
> theoretical attacks are found, keeping using hashes with known weaknesses is
> stupid.

The ISO checksums are provided more for transport verification than
for the fight against intentional mainpulation.
Signing the hash lists by PGP still seems a bit weak as protection.

But well, if Debian armors its ISOs, then it would have to scrutinize
the source of its packages, too.

Most important seems a permanent supervision of the web site content
from not publicly known client machines. Hash sums may be manipulated.
But the whole content of an ISO is either original or not. Easy to spot.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Darac Marjal wrote:
> It's difficult to provide a malicious ISO with the same MD5 as another, but
> not impossible. You can just append a certain amount of junk data until the
> hashes match.

Or you manipulate a dedicated byte array in your evil add-on. This
would avoid suspicious size changes.

Dirichlet's pidgeon hole principle tells us that in average 16 bytes
will suffice. The design goals of a hash algorithm strive for even
distribution. So the 16 byte might suffice in all cases. Quite surely
they suffice in most cases.

Nevertheless it is not yet feasible by brute force ... i guess.
Other than with MD5 "encrypted" passwords, you cannot simply create
a giant dictionary which would give you a matching input string when
you look up an MD5. Also, the passwords are in most cases shorter
than 16 bytes. So you do not need 2 exp 128 entries in your dictionary
in order to have a good chance to find a matching password.

> Similarly, you CAN do the same with SHA-1.

That would need an array of 20 bytes in average.
(Probably an algorithm would work better if it had more bytes to play
with.)

> *and* you have to keep the length the same *and* the file has to be
> coherent enough to work

These are no substantial obstacles. The only thing you need (and which
is intentionally hard to do) is reverse computation of the hash value.
I.e. find one of the many many many representants of the hash class of
that value with the given length.

Currently i wonder whether they packed up a new ISO or whether they
just patched the content of a binary file in the ISO, which is supposed
to be executed by normal installation or system use.
One could judge by comparing fake with original ISO.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Le quintidi 5 ventôse, an CCXXIV, Darac Marjal a écrit :
> It's difficult to provide a malicious ISO with the same MD5 as another, but
> not impossible. You can just append a certain amount of junk data until the
> hashes match. Similarly, you CAN do the same with SHA-1 (hash collisions ARE
> possible, but extraordinarily hard).
> 
> However, if you have to match an existing SHA-1 hash *and* you have to keep
> the length the same *and* the file has to be coherent enough to work
> (presumably the hacker's intention was to infect a target system with this
> ISO), then your chances of success are essentially zero.

You are quite wrong about the properties of hash functions. Let me correct.

If you have thousands of years of computing power at your disposal, you can
brute-force anything, of course.

If you know of a theoretical attack that nobody else knows, please share it
with the community.

Otherwise, what you write is not true.

For MD5, which has been known to be broken for a long time, cryptographers
know how to generate two useful files with the same MD5, as long as they can
control enough octets near the beginning. But the files have to be generated
together. And that is all.

Matching an existing MD5 ("preimage attack") is not currently possible, and
for SHA-1, nobody knows of a single collision, nobody knows two actual files
with the same SHA-1, let alone knows how to generate them. Both hashes have
weaknesses, but that only means brute-force will take thousands of years
instead of millions.

For now, both MD5 and SHA-1 effectively protect against tampered files. The
only known possible attack is with MD5 if the attacker can control both
files: a harmless one whose MD5 is certified by a third party and a harmful
one with the same MD5.

Of course, that does not mean MD5 and SHA-1 should be used nowadays. New
theoretical attacks are found, keeping using hashes with known weaknesses is
stupid. And of course, to avoid malicious tampering, cryptographic
signatures would be much better than plain hashes.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-23 Thread Darac Marjal


On Tue, Feb 23, 2016 at 09:39:24AM +0800, Gener Badenas wrote:



On Tue, Feb 23, 2016 at 3:23 AM, Thomas Schmitt <[1]scdbac...@gmx.net> wrote:

   Hi,

   > [2]http://thehackernews.com/2016/02/linux-mint-hack.html

   A virus of 1.5 GiB size.

   Does anybody know a download URL for such an infected ISO image ?
   (I am curious whether they used my software or mkisofs or something
   unusual.)


Will people downloading the linix mint from torrent be affected?


From what I read[1], a torrent file contains a list of the files being 
shared. That list details, for each file, the file's name, it's length 
and a series of SHA-1 hashes over the file. 

Now, the torrent file IS suspectable to the same problem: namely, if you 
fake the hashes in the torrent file, then you can claim that your 
malicious download is genuine. But if you already have the torrent file 
from before the attack (say, you are in the process of downloading it), 
then the hacker's task is made inordinately harder.


It's difficult to provide a malicious ISO with the same MD5 as another, 
but not impossible. You can just append a certain amount of junk data 
until the hashes match. Similarly, you CAN do the same with SHA-1 (hash 
collisions ARE possible, but extraordinarily hard).


However, if you have to match an existing SHA-1 hash *and* you have to 
keep the length the same *and* the file has to be coherent enough to 
work (presumably the hacker's intention was to infect a target system 
with this ISO), then your chances of success are essentially zero.



[1] https://en.wikipedia.org/wiki/Torrent_file


 


   Have a nice day :)
  
   Thomas






--
[3]Code, [4]code, [5]code, and [6]code

References:

[1] mailto:scdbac...@gmx.net
[2] http://thehackernews.com/2016/02/linux-mint-hack.html
[3] http://new.sarap.asia/
[4] http://jdk.schooluniform.asia/
[5] http://java.vpsnotes.com/
[6] http://johnmac.hephep.asia/


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Gener Badenas wrote:
> Will people downloading the linix mint from torrent be affected?

http://blog.linuxmint.com/?p=2994

"Does this affect you?

As far as we know, the only compromised edition was Linux Mint 17.3 Cinnamon
edition.
If you downloaded another release or another edition, this does not affect you.
If you downloaded via torrents or via a direct HTTP link, this doesn’t affect
you either.
Finally, the situation happened today, so it should only impact people who
downloaded this edition on February 20th."


Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Glenn English

> On Feb 22, 2016, at 6:39 PM, Gener Badenas <gener.ong.bade...@gmail.com> 
> wrote:
> 
> Will people downloading the linix mint from torrent be affected?

Don't think so. 

Google (or DuckDuckGo) for 'linux mint hacked' and you'll get lots of info with 
no "Click Here" buttons. 

One I found that way said torrent downloads weren't infected. Besides, it's all 
fixed now, and the backdoor code didn't work anyway.

-- 
Glenn English

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Gener Badenas

On Tue, Feb 23, 2016 at 3:23 AM, Thomas Schmitt  wrote:

> Hi,
>
> > http://thehackernews.com/2016/02/linux-mint-hack.html
>
> A virus of 1.5 GiB size.
>
> Does anybody know a download URL for such an infected ISO image ?
> (I am curious whether they used my software or mkisofs or something
> unusual.)
>

Will people downloading the linix mint from torrent be affected?


>
> Have a nice day :)
>
> Thomas
>
>


-- 
Code , code , code
, and code

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Sven Hartge wrote:
> You cannot wget a mega.nz URL. You have to use a Javascript-enabled
> Browser to get the file.

Shall i really enable insecure Javascript to download a malicious ISO ?

... google ... Kim Schmitz ... rofl ... i am not that curious.


Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Sven Hartge

Thomas Schmitt  wrote:
> Dalios wrote:

>> https://mega.nz/#!QwY1EZKJ!GW1gLzXaOUo8sNGF-zddRLwgsfamZy7C5u0CARjaUs0

> Only wgets a small index.html file:
>   meta name="description" content="MEGA provides free cloud storage with 
> convenient and powerful always-on privacy. Claim your free 50GB now!"
> Probably spam, i fear.

You cannot wget a mega.nz URL. You have to use a Javascript-enabled
Browser to get the file.

S°

-- 
Sigmentation fault. Core dumped.

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

Dalios wrote:
> https://mega.nz/#!QwY1EZKJ!GW1gLzXaOUo8sNGF-zddRLwgsfamZy7C5u0CARjaUs0

Only wgets a small index.html file:
  meta name="description" content="MEGA provides free cloud storage with 
convenient and powerful always-on privacy. Claim your free 50GB now!"
Probably spam, i fear.

> Have in mind that I found it in one of the thousand discussions on the
> subject in forums, blogs etc.

Yeah. I tried to find any link to that dreaded bulgarian FTP server.
No success yet.
(I even have a MD5 to identify the evil ISO: 7d590864618866c225ede058f1ba61f0
from the discussion at Mint's makeshift home.)

Well, it's purely academic. Even if i learn that xorriso was used,
i cannot keep people from bending other people's bytes.

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Dalios

On 02/22/2016 09:23 PM, Thomas Schmitt wrote:

> Does anybody know a download URL for such an infected ISO image ?
> (I am curious whether they used my software or mkisofs or something
> unusual.)

Here you go:

https://mega.nz/#!QwY1EZKJ!GW1gLzXaOUo8sNGF-zddRLwgsfamZy7C5u0CARjaUs0

Have in mind that I found it in one of the thousand discussions on the
subject in forums, blogs etc. Can't remember where exactly and can't
guarantee that it is what it says that it is so take care...

Dalios

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Charlie Kravetz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 22 Feb 2016 20:50:55 +0100
"Thomas Schmitt"  wrote:

>Hi,
>
>> Cannot say more, but the article is rather detailed.  
>
>It tells a lot about the hack and the Mint people are bravely answering
>questions.
>But my curiosity is about whether i indirectly helped the hackers.
>
>I cannot prevent such misuse of xorriso, neither practically nor legally.
>The GPL does not discriminate evil people. On the short view this might
>appear bad, but in depth it is a very wise position of Richard Stallman and
>the FSF. At least we do not risk to deny Giordano Bruno the license for ink.
>
>Nevertheless:
>
>Be Cursed, Ye Abusers Of Innocent ISO Programs !
>
>
>Have a nice day :)
>
>Thomas
>

There are several articles out now, including one that is an interview
with the hacker. Google is your friend today.

- -- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJWy24yAAoJEIqui46mydCA2hoH/jVvrWYBWFiQt9B6zglrTDn7
yDaKiFURAu0Vc5up/HqKHhcznao2N0Gd7gBbUC0EN0syHgkk4c3rzEDJOWJsgexL
bW4OPVYk6KcK2rlUaSh2PORehaDP32WVnQNstheNmYu7WroahkFysTGxlLg21qyT
IKHDyfIseKDEc7KsbiBPz6c22niWBk7a6GrkblLOV0bmh4TB4xIsK9TagGFx3j3W
8/uEARw/lrUqwzJcci6ijJQUyL46XynTnm4JvoL67a/UYIYLDj+ZOF6yzKagb1gN
9plJ8ePuBoNvm2nK5o3cAJCUlfOoAO6LQBimz3pfAaZDdcrKsSPDOYETJtvZlvs=
=nhPy
-END PGP SIGNATURE-

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

> Cannot say more, but the article is rather detailed.

It tells a lot about the hack and the Mint people are bravely answering
questions.
But my curiosity is about whether i indirectly helped the hackers.

I cannot prevent such misuse of xorriso, neither practically nor legally.
The GPL does not discriminate evil people. On the short view this might
appear bad, but in depth it is a very wise position of Richard Stallman and
the FSF. At least we do not risk to deny Giordano Bruno the license for ink.

Nevertheless:

Be Cursed, Ye Abusers Of Innocent ISO Programs !


Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

2016-02-22 Thread Karen Lewellen

The article indicates that hackers redirected the download link for one 
edition  of mint to an ftp site with their infected iso image.

Cannot say more, but the article is rather detailed.
Kare


On Mon, 22 Feb 2016, Thomas Schmitt wrote:


Hi,


http://thehackernews.com/2016/02/linux-mint-hack.html


A virus of 1.5 GiB size.

Does anybody know a download URL for such an infected ISO image ?
(I am curious whether they used my software or mkisofs or something
unusual.)

Have a nice day :)

Thomas

Re: Warning Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System

Hi,

> http://thehackernews.com/2016/02/linux-mint-hack.html

A virus of 1.5 GiB size.

Does anybody know a download URL for such an infected ISO image ?
(I am curious whether they used my software or mkisofs or something
unusual.)

Have a nice day :)

Thomas

Warning ?~@~T Linux Mint Website Hacked and ISOs replaced with Backdoored Operating System)

2016-02-22 Thread Karen Lewellen


Sharing in case anyone was impacted.


-- Forwarded message --
Date: Mon, 22 Feb 2016 08:50:44 -0800

http://thehackernews.com/2016/02/linux-mint-hack.html

[SOLVED] [OT] Has my e-mail account been hacked?

2015-10-15 Thread Stephen Powell

On Tue, 13 Oct 2015 04:15:21 -0400 (EDT), Jochen Spieker wrote:
> 
> It looks like the mail was delivered directly through
> smtp02.wow.cmh.synacor.com by a user who successfully authenticated
> using the username thecoughingcanary.

On Wed, 14 Oct 2015 05:04:55 -0400 (EDT), Brian <a...@cityscape.co.uk> wrote:
> 
> Your mails all have
> 
>   X-Authed-Username: emxpbnV4bWFuQHdvd3dheS5jb20=
> 
> The one to aol.com has
> 
>   X-Authed-Username: dGhlY291Z2hpbmdjYW5hcnlAd293d2F5LmNvbQ==
> 
> so did not come from your account.
> 
> Someone has access (legitimately or not) to the second account and is
> sending mails with a forged envelope From. Your only recourse is to
> present the evidence to the ISP and let them deal with it.

Thank you, Jochen and Brian, that is exactly the kind of information
I was looking for.  I now know that my e-mail account has not been
hacked, just spoofed.  I will report this to my ISP.  Thanks to all
who participated in this thread.

-- 
  .''`. Stephen Powell<zlinux...@wowway.com>
 : :'  :
 `. `'`
   `-

Re: [OT] Has my e-mail account been hacked?

2015-10-14 Thread Jimmy Johnson


On 10/13/2015 06:24 PM, Stephen Powell wrote:

On Tue, 13 Oct 2015 02:36:46 -0400 (EDT), Jimmy Johnson wrote:


Looks like it was mailed from MS Windows.  Maybe mailed from a Windows
OS with a virus.  Do you run Windows too?


No, I don't.  There is no computer connected to my home network that
even has Windows installed.


Okay.  Here's some info that may or may not be handy for you. Your ISP 
account, how to change your password and more: http://goo.gl/IiqWvm and 
some info from security expert Steve Gibson https://goo.gl/V85NOp .


Good luck Stephen.
--
Jimmy Johnson

Debian Stretch - Plasma 5.4.1 - AMD 64 - EXT4 at sda11
Registered Linux User #380263

Re: [OT] Has my e-mail account been hacked?

2015-10-14 Thread Brian

On Tue 13 Oct 2015 at 22:21:08 -0400, Stephen Powell wrote:

> On Tue, 13 Oct 2015 18:57:58 -0400 (EDT), Brian  wrote:
> > 
> > The comment was a general one and directed at all our readers. However,
> > earlier you said "Someone discovered my password somehow". You have
> > just demolished that guess as having no basis as a likely cause.
> 
> Likely, no, but still possible.  For example, when I update my web
> pages, I use my ISP's FTP server.  Suppose someone else on my ISP's subnet
> has a network sniffer in promiscuous mode.  The FTP server uses ordinary
> unencrypted FTP.  The userid and password are sent in clear text.  I wish
> they had an FTPS server, but the last time I checked, they didn't.  I use
> e-mail solely through a web-based e-mail client.  When I login, I don't
> know if the password is sent in clear text over the network or not.
> 
> That being said, if my password was obtained in this manner, I don't have
> much of a defense against it.  If I change my password, they can get the
> new one the same way as they got the old one.
> 
> Another possibility is a malicious web site that I may have unknowingly
> visited that managed to find a password in memory, a cookie, etc.  So
> despite all the precautions that I have taken, it is still possible for
> a password to be "discovered".
> 
> Having said that, it looks like someone else's credentials may have been
> used, based on some other posts to this thread.  But I am not an expert
> in these matters.  That's why I asked for help.

Your mails all have

  X-Authed-Username: emxpbnV4bWFuQHdvd3dheS5jb20=

The one to aol.com has

  X-Authed-Username: dGhlY291Z2hpbmdjYW5hcnlAd293d2F5LmNvbQ==

so did not come from your account.

Someone has access (legitimately or not) to the second account and is
sending mails with a forged envelope From. Your only recourse is to
present the evidence to the ISP and let them deal with it.

Re: [OT] Has my e-mail account been hacked?

2015-10-14 Thread Timothy Hobbs

Say that you are using the Desktop version of Android(tm). It's pretty 
close to the truth.


On 10/14/15 05:33, Stuart Longland wrote:

On 14/10/15 13:23, John Hasler wrote:

Lie.  Tell them you're running Windows 95.

"Ohh sorry, we only support Windows 7 or 8"

Re: [OT] Has my e-mail account been hacked?

2015-10-14 Thread Carl Fink

On Wed, Oct 14, 2015 at 01:33:02PM +1000, Stuart Longland wrote:
> On 14/10/15 13:23, John Hasler wrote:
> > Lie.  Tell them you're running Windows 95.
> 
> "Ohh sorry, we only support Windows 7 or 8"

I can truthfully say that my Android-based tablet can't get access. It's
hard for ISPs not to support tablets.
-- 
Carl Fink   nitpick...@nitpicking.com 

Read my blog at blog.nitpicking.com.  Reviews!  Observations!
Stupid mistakes you can correct!

Re: [OT] Has my e-mail account been hacked?

On 14/10/15 13:23, John Hasler wrote:
> Lie.  Tell them you're running Windows 95.

"Ohh sorry, we only support Windows 7 or 8"

-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature

Re: [OT] Has my e-mail account been hacked?

On 14/10/15 12:51, Stephen Powell wrote:
> Their level 1 help desk isn't much help anyway, if you're a Linux user.
> The last time I called their level 1 help desk for technical support, the
> conversation went something like this:

Yep, familiar story.  Some can't get it through their thick heads that
you want support for the *internet connection* and not the computer
connected to it.  If it isn't in their script, they don't know anything
about it and don't want to know.

> And that was that.  They'll gladly take the money of a Linux user.
> But if you have problems, you're on your own.  That was a few years ago.
> Maybe it's better now.

True, as I said, this isn't L1 helpdesk material, I gave details of a
WHOIS look-up that gave an email address and telephone number you could
contact.

You'll probably note this is a different email address to your regular
helpdesk contact details, and for good reason.  It is for a totally
different audience: a technical one who know how to work the `whois`
tool, know what an IP address is, and know that a serial port isn't a
place for sailors to eat breakfast.

Forward them the bounce emails you've been getting, then the ball is in
their court.  I do know what it is like to deal with a clueless
helpdesk, spent many hours on the phone with a few here.

-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

signature.asc
Description: OpenPGP digital signature

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Stephen Powell

On Tue, 13 Oct 2015 11:22:34 -0400 (EDT), Andrew McGlashan wrote:
> 
> On 13/10/2015 7:15 PM, Jochen Spieker wrote:
>> Stuart Longland: I had a similar case on my self-administered mail
>> host. A friend of mine has an account there and random hosts from
>> all over the world used his credentials to send legitimately
>> looking spam. We never found out how this happened but changing the
>> password was enough to make it stop.
> 
> Odds on it was open WiFi somewhere, people trust public WiFi ... I
> cannot understand why.  It is patently stupid [or ignorant at best] to
> use public [or otherwise open] WiFi -- if you don't run it yourself or
> you totally trust the person whom is running it, then leave it alone.

That may have been the case for Stuart's friend, but it is not the case
with me.  I use only wired ethernet.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Stephen Powell

On Tue, 13 Oct 2015 22:09:53 -0400 (EDT), Stuart Longland wrote:
> 
> This isn't level 1 helpdesk material, you'll actually need a technical
> contact there.

Their level 1 help desk isn't much help anyway, if you're a Linux user.
The last time I called their level 1 help desk for technical support, the
conversation went something like this:

Me:   I'm having an internet connectivity problem.  I can't 
Them: What release of Windows are you running?
Me:   I don't run Windows; I run Linux.
Them: I'm sorry, sir, we don't support Linux.
Me:   This is not a Linux problem.  This is an internet connectivity problem.
  I can't ...
Them: I'm sorry, sir, we don't support Linux.  Is there anything else we
  can help you with today, sir?
Me:   No, I don't think so.

And that was that.  They'll gladly take the money of a Linux user.
But if you have problems, you're on your own.  That was a few years ago.
Maybe it's better now.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [OT] Has my e-mail account been hacked?

On 14/10/15 11:53, Stephen Powell wrote:
> On Tue, 13 Oct 2015 04:15:21 -0400 (EDT), Jochen Spieker wrote:
>>
>> Stuart Longland:
>>> On 13/10/15 09:58, Stephen Powell wrote:

 Unfortunately, I don't.  Attached below is one of the mail delivery
 failure notices, which includes the headers of the original message.
 But I don't understand what it all means.
>> …
 Authentication-Results:  smtp02.wow.cmh.synacor.com 
 smtp.user=thecoughingcanary; auth=pass (LOGIN)

>>> Not sure about this one.
>>
>> It looks like the mail was delivered directly through
>> smtp02.wow.cmh.synacor.com by a user who successfully authenticated
>> using the username thecoughingcanary.
>>
>> @Stephen: is that you?
> 
> No.  My id on this mail server is "zlinuxman".  I have no idea who
> "thecoughingcanary" is.  Nor do I understand why the SMTP server would
> allow "thecoughingcanary" to send out e-mails in my name, unless
> "thecoughingcanary" is an administrator account.

This is making a lot more sense now.  So 'wowway.com' is your ISPs
server, and 'thecoughingcanary' is another customer of theirs.  Likely a
compromised one.  Your ISP needs to know about this.

Why did it allow the email to be relayed?  Well, the credentials were
correct, that's all that was needed.  (Yes, SMTP is that basic.)

You'd probably find you can send email from *any* email address you
choose, provided that the email address domain permits that server to
send emails from that domain.

(e.g. my domain has SPF records that only permit a small handful of
servers to send emails with a 'longlandclan.id.au' domain.  Anyone else
will trigger a "soft-failure".)

This isn't level 1 helpdesk material, you'll actually need a technical
contact there.

> Registrant Name: WIDEOPENWEST LLC
> Registrant Organization: WIDEOPENWEST LLC
> Registrant Street: 1323 Bond St.
> Registrant City: Naperville
> Registrant State/Province: IL
> Registrant Postal Code: 60563
> Registrant Country: US
> Registrant Phone: +1.6305363161
> Registrant Phone Ext: 
> Registrant Fax: +1.6305363108
> Registrant Fax Ext: 
> Registrant Email: unixadm...@wideopenwest.com

My first point of call would be that 'unixadm...@wideopenwest.com' as it
now appears you're seeing the bounce traffic from another customer's
compromised host.  I'd forward them a sample of the bounce traffic.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

signature.asc
Description: OpenPGP digital signature

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Andrew McGlashan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 14/10/2015 12:53 PM, Stephen Powell wrote:
> No.  My id on this mail server is "zlinuxman".  I have no idea who 
> "thecoughingcanary" is.  Nor do I understand why the SMTP server
> would allow "thecoughingcanary" to send out e-mails in my name,
> unless "thecoughingcanary" is an administrator account.

Perhaps this business has an account on the mail server and they have
a configuration problem.

http://coughingcanary.com/

>> Who runs this mail service?
> 
> Wide Open West, or "Wow!" as they market themselves.
> 
> http://wowway.net/

They /may/ also use this ISP.

Also, a cable Internet connection shares a network segment with a
bunch of people potentially.  So, perhaps, just perhaps, they are on
your segment to get the creds.  More likely they are using their own
creds if the business has their own account with your ISP.

> It's basically a cable TV company.  I have a bundle of cable,
> internet, and phone service from them.  They provide free e-mail
> and a free web-hosting service to all who subscribe to their
> internet service. My connectivity is through a cable modem which
> they provide. I have my own wired ethernet router connected to it,
> and my computers connect to that.

Being a "cable TV company" ... perhaps, again perhaps, they haven't
got things nice and secure themselves.

Kind Regards
AndrewM
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYdvTUACgkQqBZry7fv4vud/QEAv27pKUZyF2QRs927sTDctMis
xN6i0eDDVgZ0OeGU07oA/jg/4Fjq1rUZPK5DxirBGX2KYDzOGkkF7Wk82qYZou1X
=XSfw
-END PGP SIGNATURE-

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Andrew McGlashan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 14/10/2015 1:09 PM, Stuart Longland wrote:
>> No.  My id on this mail server is "zlinuxman".  I have no idea
>> who "thecoughingcanary" is.  Nor do I understand why the SMTP
>> server would allow "thecoughingcanary" to send out e-mails in my
>> name, unless "thecoughingcanary" is an administrator account.

Yes, that can be a serious problem; any ONE user can compromise others.

> This is making a lot more sense now.  So 'wowway.com' is your ISPs 
> server, and 'thecoughingcanary' is another customer of theirs.
> Likely a compromised one.  Your ISP needs to know about this.

Yep.

> Why did it allow the email to be relayed?  Well, the credentials
> were correct, that's all that was needed.  (Yes, SMTP is that
> basic.)

Right.

> You'd probably find you can send email from *any* email address
> you choose, provided that the email address domain permits that
> server to send emails from that domain.
> 
> (e.g. my domain has SPF records that only permit a small handful
> of servers to send emails with a 'longlandclan.id.au' domain.
> Anyone else will trigger a "soft-failure".)

SPF is only good if the receiving server does proper checks and you
don't have a soft fail in your setup.  Too many servers don't seem to
care about SPF failing, which is why back scatter is [or was] a much
greater problem that it should ever have been.

A.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYdyoQACgkQqBZry7fv4vuA9gD+IvJyS7o4qSNJo/hKW+heUe11
zmxAEtvo5lI9NvR65JMBAJUnLst8W/l+gj0lysa2B7G2oVfcRQzUGvu0b7c+NNyv
=Eshk
-END PGP SIGNATURE-

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread John Hasler

Stephen Powell writes:
> And that was that.  They'll gladly take the money of a Linux user.
> But if you have problems, you're on your own.

Lie.  Tell them you're running Windows 95.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Stephen Powell

On Tue, 13 Oct 2015 18:57:58 -0400 (EDT), Brian  wrote:
> 
> The comment was a general one and directed at all our readers. However,
> earlier you said "Someone discovered my password somehow". You have
> just demolished that guess as having no basis as a likely cause.

Likely, no, but still possible.  For example, when I update my web
pages, I use my ISP's FTP server.  Suppose someone else on my ISP's subnet
has a network sniffer in promiscuous mode.  The FTP server uses ordinary
unencrypted FTP.  The userid and password are sent in clear text.  I wish
they had an FTPS server, but the last time I checked, they didn't.  I use
e-mail solely through a web-based e-mail client.  When I login, I don't
know if the password is sent in clear text over the network or not.

That being said, if my password was obtained in this manner, I don't have
much of a defense against it.  If I change my password, they can get the
new one the same way as they got the old one.

Another possibility is a malicious web site that I may have unknowingly
visited that managed to find a password in memory, a cookie, etc.  So
despite all the precautions that I have taken, it is still possible for
a password to be "discovered".

Having said that, it looks like someone else's credentials may have been
used, based on some other posts to this thread.  But I am not an expert
in these matters.  That's why I asked for help.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Adrian O'Dell




On 10/13/2015 09:51 PM, Stephen Powell wrote:

On Tue, 13 Oct 2015 22:09:53 -0400 (EDT), Stuart Longland wrote:

This isn't level 1 helpdesk material, you'll actually need a technical
contact there.

Their level 1 help desk isn't much help anyway, if you're a Linux user.
The last time I called their level 1 help desk for technical support, the
conversation went something like this:

Me:   I'm having an internet connectivity problem.  I can't 
Them: What release of Windows are you running?
Me:   I don't run Windows; I run Linux.
Them: I'm sorry, sir, we don't support Linux.
Me:   This is not a Linux problem.  This is an internet connectivity problem.
   I can't ...
Them: I'm sorry, sir, we don't support Linux.  Is there anything else we
   can help you with today, sir?
Me:   No, I don't think so.

And that was that.  They'll gladly take the money of a Linux user.
But if you have problems, you're on your own.  That was a few years ago.
Maybe it's better now.

Not likely any better now. You should just lie to them about what you're 
using.

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Andrew McGlashan

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Of course ftp, clear text passwords, is also a problem; if it was
this, then every time you update files via ftp, can you then
immediately change your password when done?  Mute point if they are
using their own credentials to send mail and not your creds.

A.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYdy0oACgkQqBZry7fv4vuTDAD/Zg2XpzoJHxfUlwvwKDloCz5u
ur0bcci0t7l8lCLdDsYA/iibcykffxcQHZwxynPPdjiQg0vLHTVvvHlqWx8ylUYb
=K8AT
-END PGP SIGNATURE-

Re: [OT] Has my e-mail account been hacked?

2015-10-13 Thread Jimmy Johnson


On 10/12/2015 04:58 PM, Stephen Powell wrote:

On Mon, 12 Oct 2015 16:53:05 -0400 (EDT), Stuart Longland wrote:


I'd check the backscatter case, as this requires no skill on the part of
the attacker and is the most likely case.
...
It's worth knowing how to read the headers of emails in this
circumstance as it can give you vital information for knowing what is
going on.


Unfortunately, I don't.  Attached below is one of the mail delivery
failure notices, which includes the headers of the original message.
But I don't understand what it all means.  Perhaps you or someone else
out there can make some sense of it and advise me accordingly.
Remember, I never sent the original e-mail.  I just got the delivery
failure notice.



X-MSMail-Priority: Normal



X-Mailer: Microsoft Outlook Express 6.00.2800.1081 <



X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081



Looks like it was mailed from MS Windows.  Maybe mailed from a Windows 
OS with a virus.  Do you run Windows too?

--
Jimmy Johnson

Debian - Wheezy - KDE 4.8.4 - AMD64 - EXT4 at sda1
Registered Linux User #380263

Re: [OT] Has my e-mail account been hacked?