Re: Message de Benjamin MABILLE / CCA

[AK]

Dear debian-security ML,

I thing that the situation with Out-Of-Office replies is getting a bit
out of hand. Can someone please temporarily unsubscribe the offending
parties? It does not reflect to the quality of the list. If the
moderators are too busy with other things, I can volunteer some of my
daily time to help with moderation, if so needed.

Best Regards,
AK
On 5/9/12 7:38 PM, Mabille Benjamin wrote:
> Bonjour,
>
> J'ai bien recu votre message, je suis actuellement en conges et je serai de 
> retour le Mardi 15 mai 2012.
>
> En mon absence, vous pouvez contacter notre standard au 0826 80 80 80 ou le 
> service technique a l'adresse techni...@intracall.com
>
> Cordialement,
>
> CCA International
> Benjamin MABILLE
> Développeur
>
> 42-46 rue Riolan 
> 80 000 Amiens - France
> tel. +33 3 22 82 02 57
> www.ccainternational.com
>
>


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4faab164.2030...@gmail.com

Re: some feedback about security from the user's point of view

[AK]

Hi all,

Another indicator that I believe should be taken care into
consideration, is the fact that Microsoft is using SHA256 or better in
all new application for a while now. They do have a post [1] in their
Secure Development Lifecycle blog stating their stance regarding
cryptography and banning certain algorithms and the reasoning behind
some decisions (albeit a watered-down one). Regardless of one's views
for Microsoft (I personally do not use any of their products), I believe
that one should see what others in the are doing

[1]
http://blogs.msdn.com/b/sdl/archive/2009/07/16/banned-crypto-and-the-sdl.aspx

On 01/24/2011 01:18 PM, René Mayrhofer wrote:
> Am Montag, 24. Januar 2011, um 11:29:25 schrieb AK:
>> While the attack sequence presented is valid, in practice, given that
>> there are a lot of "Debian based" distributions out there, wouldn't this
>> be caught somewhere down the line?
> I wouldn't count on it, unfortunately - I have been working on a 
> security/firewall distribution based on Debian (Gibraltar firewall) since ca. 
> 2000, and we just don't have the manpower to audit upstream Debian packages. 
> We certainly didn't catch the openssl bug, and I don't think any of the other 
> Debian-derived distributions did. It would be exceedingly easy to hide a 
> small, known-to-be-colliding binary block in most of the Debian packages and 
> call it with an obscure overflow-like bug in one of the binaries.
>
> Therefore, I strongly suggest to move away from all uses of MD5 and use SHA-2 
> (>=256) instead (SHA1 already makes the crypto community nervous, and we will 
> need to wait for SHA-3 to arrive at something that will hopefully hold for 
> >10 years...).
>
> best regards,
> Rene


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3d65ab.8030...@gmail.com

Re: some feedback about security from the user's point of view

[AK]

Hi all,

While the attack sequence presented is valid, in practice, given that
there are a lot of "Debian based" distributions out there, wouldn't this
be caught somewhere down the line?

Having said that, I fully agree that MD5 should no longer be recommended.

On 01/24/2011 09:42 AM, René Mayrhofer wrote:
> Am Sonntag, 23. Januar 2011, um 20:52:44 schrieb AK:
>> Regarding the MD5 sum example and certain released PoCs: producing two
>> "random" files with identical MD5 sums is one thing, introducing a
>> meaningful backdoor (which means deterministic change) or ten in a
>> Debian iso and generating an iso file which is similar in size to the
>> original one and has an identical MD5 sum might be a tad more
>> computationally difficult (this is my estimation), especially for
>> something as short-lived as a Linux CD image.
> With control over a single Debian package (read: when a Debian developer is 
> in on the attack), it could be easily done including plausible deniability 
> for the involved developer:
>
> 1. Place a random (but large enough) binary blob into a binary installed by a 
> package. The binary blob in the Debian package as uploaded to the archive is 
> competely harmless and may just look odd (if it was detected, that is).
>
> 2. Create a second binary blob with a collision (but with harmful content). 
> This is fairly easy to do if the two blobs are similar save for a small, 
> known-to-collide part.
>
> 3. Wait for the uploaded package to appear in an ISO and the MD5 sums to be 
> created
>
> 4. Replace the binary blob, the MD5 sum still matches.
>
> 5. Give somebody the changed ISO
>
> So yes, MD5 should no longer be recommended.
>
> best regards,
> Rene


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d3d5485.4050...@gmail.com

Re: some feedback about security from the user's point of view

[AK]

Thanks for the reply and the links Robert.

 I agree with your point on SSL/TLS not being as computationally
expensive as it used to be, however (as you correctly state) it can be
more of an issue regarding management/resources, as well as red tape.
Regarding Google's statement with SSL/TLS cost being negligible, while I
empirically agree with this one (e.g. in our project's infrastructure
un-accelerated SSL overhead was minimal, even though by default we
employ the strongest cipher suits of it), again this falls into a matter
of integrating SSL into existing infrastructure, a cost that might not
be readily available justifiable to a bureaucratic environment, such as
a university. To put it a bit colloquially, downloading Debian ISOs over
encrypted or unencrypted HTTP will not cause any fluctuation on the
amount of daily sleep I get :)

Regarding the MD5 sum example and certain released PoCs: producing two
"random" files with identical MD5 sums is one thing, introducing a
meaningful backdoor (which means deterministic change) or ten in a
Debian iso and generating an iso file which is similar in size to the
original one and has an identical MD5 sum might be a tad more
computationally difficult (this is my estimation), especially for
something as short-lived as a Linux CD image. Adding into account that
this trick can easily be rendered useless if the end user chooses let's
say SHA256 as opposed to MD5 to verify the downloaded file (and banished
altogether by a simple announcement by Debian team along the lines
of "please use SHA256 to verify all downloads from us". I fully agree
with the removal of MD5 as a sign of "keeping with the times" though.


On 01/23/2011 08:04 PM, Robert Tomsick wrote:
> On Sun, 2011-01-23 at 19:34 +0200, AK wrote:
>
>> a small disclaimer first, I am not affiliated with debian in any way,
>> I am, as the original author would have put it a user. 
> The same goes for me, so I suppose my remarks should be taken with a
> comparably-sized grain of salt. :)  That said:
>
>> 1) Why is *getting* debian over plain HTTP such a big issue? Assuming
>> that even you get a tampered .iso, it is trivial to verify that it is
>> not the genuine one, even in using a "broken" hash algorithm such as
>> MD5. SSL-enabling all downloads from Debian would have the unfortunate
>> side effects of increasing the load on the servers, requiring more
>> budget from the Debian team, as well as meaning losing a few mirrors
>> around the globe. Personally, I view it as a reasonable risk, provided
>> that the end user verifies the .iso image before installing. 
> I think the resistance to the idea isn't so much from the fact that the
> use of SSL is a panacea -- there are obviously numerous ways that one
> can wind up with a compromised OS, the initial download is but one of
> them -- but rather that it would provide a good "first layer" of
> protection against tampering.
>
> While I have done no measurements of this myself, there seems to be some
> [1] consensus [2] that SSL doesn't actually impose nearly as much
> overhead as people think it does, especially if you're dealing with
> long-lasting connections.  Obviously there is a good bit of management
> overhead associated with deployment and administration, but at least
> from the performance standpoint it seems (to my untrained eye) like the
> "SSL == serious performance hit" issue has been at least partially
> conquered by Moore's law.  From one of the Google engineer's postings
> [2] on the subject:
>
> "In January this year (2010), Gmail switched to using HTTPS for
> everything by default. [...] In order to do this we had to deploy no
> additional machines and no special hardware. On our production frontend
> machines, SSL/TLS accounts for less than 1% of the CPU load, less than
> 10KB of memory per connection and less than 2% of network overhead. Many
> people believe that SSL takes a lot of CPU time and we hope the above
> numbers (public for the first time) will help to dispel that.
>
> If you stop reading now you only need to remember one thing: SSL/TLS is
> not computationally expensive any more."
>
> [1]
> http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose
>
> [2] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html 
>
>
>> Regarding MD5, while indeed it has been broken, is it not sufficient
>> for simple checksumming purposes? I have not looked throughly into
>> this
>> so please feel free to correct me but how practical would have been
>> for
>> someone to create a meaningful debian .iso AND introduce backdoors
>> to it
>> AND create a MD5 sum that matches the original one? Are there a

Re: some feedback about security from the user's point of view

[AK]

Hi all,

a small disclaimer first, I am not affiliated with debian in any way, I
am, as the original author would have put it a user. I would like to
play devil's advocate in a few of the quite interesting points that Naja
raises:

1) Why is *getting* debian over plain HTTP such a big issue? Assuming
that even you get a tampered .iso, it is trivial to verify that it is
not the genuine one, even in using a "broken" hash algorithm such as
MD5. SSL-enabling all downloads from Debian would have the unfortunate
side effects of increasing the load on the servers, requiring more
budget from the Debian team, as well as meaning losing a few mirrors
around the globe. Personally, I view it as a reasonable risk, provided
that the end user verifies the .iso image before installing. 

2) Regarding MD5, while indeed it has been broken, is it not sufficient
for simple checksumming purposes? I have not looked throughly into this
so please feel free to correct me but how practical would have been for
someone to create a meaningful debian .iso AND introduce backdoors to it
AND create a MD5 sum that matches the original one? Are there any
examples of it in the wild? Having said that, I am all for the use of
SHA256 or better in all newer examples/hashes, I cannot stress how
strongly I agree, even for the sake of "modernizing".

3) Regarding policies, I think that unfortunately Debian has a bad
record (cough, cough, openSSL PRNG circa 2008) so what is the current
situation? This is partially mitigated by the work performed by the
security team who kill bugs on a daily basis. Granted, this is a bit
after the fact but bugs get killed. Again, I fully agree with the author
however how such a centralized management "tool" such as policies can be
applied to an all open-source distribution, such as Debian? Does that by
extension means that Debian developers have to proactively seek out
possible security bugs in other's people code?

Having said the above, the question is how could someone help by
donating time/skills to address the points raised by the original poster?

Cheers!


On 01/23/2011 06:35 PM, Naja Melan wrote:
> Hi,
>
> quite some people around me use debian with view of creating secure
> encrypted systems. Consider for example in france boum.org, who have
> published a book about computer security which advises people to use debian.
> Those people turn to me with questions about how safe things are and want
> advice for their practices.
>
> Some weeks ago I decided to have a look at debian and quite soon ran into
> questions and problems considering the security of debian. I would like to
> share some of those questions, remarks in this mail in the hope of
> stimulating a discussion and hopefully a more secure future for all of us as
> quite a few are going to need it and depend on it.
>
> Something that immediately drew my attention was the choice of
> debian.orgnot to have a certified SSL connection. I can see the
> reasons for this, and
> I am also aware of the limits in SSL, but I still want to raise the issue of
> being able to obtain a copy of debian with a higher degree of security than
> plain http. I set of to try to do that and the following describes my
> experiences:
>
> I ended on this page: http://debian.org/distrib/ which is quite short and I
> quite some information on this page http://debian.org/CD/http-ftp/ is also
> important for people using other methods of download like torrents however
> they don't get to see it (e.g. you only need disc 1 to install a standard
> debian system). Information regarding verifying the downloads is completely
> lacking from these pages which occurs to me to be odd. I finally found via
> google that it is in the faq:
> http://debian.org/CD/faq/#verify
>
> The instructions here are quite problematic. First of all, they advise the
> use of md5 which has been broken .
> It occurs to me that changing this documentation to use another hash would
> be trivial. If security advice from debian suggests the use of md5, it also
> makes me wonder where else in the debian operating or package system md5
> still gets used. It doesn't make me feel safe if an operating system does
> not have a policy to replace all occurrences of a certain cryptographic
> function after it has been broken. What is the position of the debian
> development/security team on this?
>
> Next the instructions in the faq suggest that the user can verify the
> correctness of these hashes with the pgp signature. This makes 2 problematic
> assumptions. First it assumes that users are in the web of trust and have a
> means of verifying the debian pgp key. Secondly it assumes that users
> understand the way a web of trust works and also is aware of the limits and
> vulnerabilities of it, as well as understands how to use it correctly.
> Considering that more and more less geeky people start to use linux systems,
> those assumptions exclude a growing group of users which are no

Re: tty's messages

[ak]

On Mon, Dec 22, 2003 at 10:23:56AM +0200, E&Erdem wrote:

change in /etc/init.d/klogd line contains
KLOGD=""
to
KLOGD="-k /boot/System.map-$(uname -r) -c4"
option -c4 fixes your problem.
greetz,
Artur


> Hi,
> >From i've set up iptables i've get this messages continual on tty's
> (console):
> 
> ___
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53147 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:60:08:4d:7d:8a:08:00
> SRC=195.174.17.192 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=9914
> PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:30:4f:29:2f:0f:08:00 SRC=0.0.0.0
> DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=29 PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53273 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:50:fc:be:a3:e7:08:00
> SRC=195.174.31.136 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=723
> PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53408 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:50:fc:d4:65:35:08:00
> SRC=195.174.81.211 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=951
> PROTO=2
> ___
> 
> So i can't use tty's [F1 to F6]. How can i solve this?
> 
> Thanks...
> -- 
> __
>  E&Erdem
> -- 
>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

Re: tty's messages

[ak]

On Mon, Dec 22, 2003 at 10:23:56AM +0200, E&Erdem wrote:

change in /etc/init.d/klogd line contains
KLOGD=""
to
KLOGD="-k /boot/System.map-$(uname -r) -c4"
option -c4 fixes your problem.
greetz,
Artur


> Hi,
> >From i've set up iptables i've get this messages continual on tty's
> (console):
> 
> ___
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53147 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:60:08:4d:7d:8a:08:00
> SRC=195.174.17.192 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=9914
> PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:30:4f:29:2f:0f:08:00 SRC=0.0.0.0
> DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=29 PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53273 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:50:fc:be:a3:e7:08:00
> SRC=195.174.31.136 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=723
> PROTO=2 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:00:21:11:97:f8:08:00
> SRC=195.174.81.188 DST=224.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=50
> ID=53408 PROTO=UDP SPT=4942 DPT=5000 LEN=40 
> IN=eth1 OUT= MAC=01:00:5e:00:00:01:00:50:fc:d4:65:35:08:00
> SRC=195.174.81.211 DST=224.0.0.1 LEN=28 TOS=0x00 PREC=0x00 TTL=1 ID=951
> PROTO=2
> ___
> 
> So i can't use tty's [F1 to F6]. How can i solve this?
> 
> Thanks...
> -- 
> __
>  E&Erdem
> -- 
>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]