Re: the frustrated administrivia and misdirection hose lacks any abatement visible to mortals

2016-05-23 Thread Drake Wilson
On Mon, May 23, 2016, at 14:21, K & K Ruzicka-Eigenbauer wrote:
> UNSUBSCRIBE

Coming back to the horribly irritating and persistent flood of this---I filed 
#821113 a
month ago about this, but the listmasters said I should ask the security team 
instead,
since they set the policy for their own lists.

Lacking any obvious way to talk to the security team without potentially making 
my
message look more urgent than it was, I leave it to whoever else can navigate 
the
Debian social structure to take it up in the most appropriate manner.  I've 
absolutely run
out of nerves for having to clear this garbage out of my mailpile, so I'm done 
here.

   ---> Drake Wilson



Re: [SECURITY] [DSA 3547-1] imagemagick security update

2016-04-12 Thread Drake Wilson
Bjoern Nyjorden wrote:
> Hi Luciano and others,
> 
> AS AT: 2230(+0800) (1430(+)):
> 
>   * Imagemagick  version 8:6.7.7.10-5+deb7u4 is STILL NOT AVAILABLE at:
> 
> 
> http://security.debian.org/debian-security/pool/updates/main/i/imagemagick/

They look good to me at the moment (2016-04-12T15:32:46Z), but I don't have a
log of when I first saw them appear.

Are you sure you don't have a strange transparent HTTP cache or something 
between
you and security.debian.org which might be ignoring the cache-control headers?
With what client software and from what network location are you accessing that
URL, and have you tried with a different client or from a different host?

   ---> Drake Wilson



Re: gmonstart / jvregisterclasses in tons of binaries with commands, malware?

2009-12-16 Thread Drake Wilson
Quoth whereislibertyandjust...@safe-mail.net, on 2009-12-16 17:59:13 -0500:
 Whether I run 'strings' on the binary files or view with vim or gedit, here
 is what is always seen inside the binaries:
 
 __gmon_start__
 _Jv_RegisterClasses

These are internal symbols generated by the compiler.  __gmon_start__
is used for profiling, and _Jv_RegisterClasses is part of the GCJ Java
ABI, at least based on a cursory glance at the GCC source.

You might notice that an executable freshly compiled with GCC 4.3 from
unstable has these symbols as weak symbols.  I would hazard a guess
that they're stub functions called from common startup code in case
the relevant object files get linked with Java code or anything with
profiling enabled (in which case the real functions would be pulled in
and override the stubs).

 I've purchased Linux CDs from brick + mortar stores, downloaded ISOs
 from different physical locations and found some CDs contained these
 strings in the binaries and one or two rare ones did not, but when
 installed/updated on a network connection the binaries replaced in
 the update process would show these strings!

In other words, most likely, you upgraded the binaries from versions
compiled with an old compiler (and therefore not having the same
internal symbols) to ones compiled with a new compiler.

As for OpenBSD, it's entirely plausible that a different platform
would port the compiler differently, or use more aggressive symbol
stripping, or a slightly different C library, or any number of other
things that might perturb the internal symbols, since they're not
meant to be highly stable and portable.

 every Linux user I've asked to date calls me paranoid

I'd have to agree on that one, in this regard.

 The strings may/may not be common, but in comparing commands which
 follow these strings I've noticed some which seem down right
 malicious!

This is a pretty ill-defined statement, but I'm curious what strings
exactly you've seen that make you think this.  Of course, it's
impossible for me to determine definitively that you don't have some
_other_ hostile factor on your machine.

   --- Drake Wilson


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org