Fun job: Please test/review patch for picocom CVE-2015-9059

[W. Martin Borgert]

Hi security,

there is a problem with the picocom terminal emulator:


picocom before 2.0 has a command injection vulnerability in the
'send and receive file' command because the command line is
executed by /bin/sh unsafely.

(https://security-tracker.debian.org/tracker/CVE-2015-9059)

The bug report https://bugs.debian.org/863671 contains a patch,
but I'm not sure whether it does what it should.

A test case would be wonderful!

If nobody can review or test the patch, there are other options:

 - remove picocom 1.7 from stretch (2.2 is in experimental and
   does not have the vulnerability, it will be in unstable ASAP
   and will be backported to both Stretch and Jessie)

 - just disable 'send and receive file', which nowadays is not
   very important anymore, I need to check how easy this is,
   but I'm optimistic

 - document the problem, but ignore it otherwise, because not
   many people will use file transfer anyway - this is neither
   heartbleed nor shellshock; no fancy name, no logo

TIA & Cheers

Re: Handling of "malware" in Debian

[W. Martin Borgert]

On 2016-11-10 09:45, Paul Wise wrote:
> My intuition says that there are users who don't have apt-listchanges
> installed or don't read the NEWS files. The most likely place folks
> will see the notification is in the UI of the malware package itself.

This is true. OTOH, if the WOT UI is gone, users will either not
care (good) or ask themselves where it is gone and can still
check the package (good, too). It's not, that the user or root
would have to perform any action.

Re: [Pkg-mozext-maintainers] Handling of "malware" in Debian

[W. Martin Borgert]

On 2016-11-09 19:34, Ximin Luo wrote:
> Context for the new list you added, please?

#842939

Is it OK, if I do the upload? I'm in the team, but David Prévot
did previous uploads.

Cheers

Re: Handling of "malware" in Debian

[W. Martin Borgert]

Quoting Holger Levsen :

i'm not sure about the releasing with stretch part. Maybe it would be
better to have the updated, empty package in stretch in 5plusX days and
then remove it before the release, say on January 1st.


Ah, OK. Understood. Well, maybe As Short As Possible before the release,
during DC17 :~)

Re: Handling of "malware" in Debian

[W. Martin Borgert]

Quoting Holger Levsen :

I think so. And I also think this should be done.

and, who's gonna file the RM bug for unstable?


I would RM for buster, because users of stretch might already be affected.

Re: Handling of "malware" in Debian

[W. Martin Borgert]

Quoting Paul Wise :

A new empty package would be better than just removing it but the user
would not get any notification about why the functionality is gone nor
any information about the privacy violations they were subject to.


Would NEWS.Debian be sufficient?

Handling of "malware" in Debian

[W. Martin Borgert]

Hi,

because of the WOT[*] incident, I wonder how Debian should handle
malware packages in favour of our users.

The current scheme is to remove the offending package from stable and
go along. With unattended-upgrades or other automatic upgrade schemes,
such packages would remain on many systems and potentially harm users.

I suggest to handle such cases differently by uploading a new, empty
package (like transitional packages, but without new depends).

What do you think?

Cheers

[*] https://bugs.debian.org/842939

Re:

[W. Martin Borgert]

On 2015-05-11 22:33, Johannes Wolpers wrote:
 htmlhead/headbodydiv style=font-family: Verdana;font-size: 
 12.0px;divI will dominate this world one day

Please do not send HTML formatted email to mailing lists.
It makes them difficult to read for us mutt users. Dankeschön!


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150512070117.GA6686@fama

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[W. Martin Borgert]

On 2014-09-24 23:05, Hans-Christoph Steiner wrote:
 * the signature files sign the package contents, not the hash of
   whole .deb file (i.e. control.tar.gz and data.tar.gz).

So preinst and friends would not be signed? Sounds dangerous to me.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925035052.GA20936@fama

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[W. Martin Borgert]

On 2014-09-21 20:04, Elmar Stellnberger wrote:
A package with some new signatures added is no more the old package.
 It should have a different checksum and be made available again for update.
 Perhaps someone wants to install the package not before certain signatures
 have been added.

If a package would change by adding another signature, then this
would invalidate previous signatures. Exactly because of your
use case (waiting for a number of signatures or waiting for a
specific signature before installation) the signature must be
separated from the actual package.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140921182918.GA27550@fama

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[W. Martin Borgert]

On 2014-09-21 21:13, Richard van den Berg wrote:
 Package formats like apk and jar avoid this chicken and egg problem by 
 hashing the files inside a package, and storing those hashes in a manifest 
 file.

Is there a chicken and egg problem? Only if one insists on embedding
the signatures in one file, I would say.

 Signatures only sign the manifest file. The manifest itself and the signature 
 files are not part of the manifest, but are part of the package. So a package 
 including it's signature(s) is still a single file.

This is nice, indeed, but: The Debian repository is mirrored all over
the world and distributed on DVSs/CDs. If package files change
whenever a signature is added, this would lead to needless traffic and
obliterate readonly media.

(Well, rsync would mitigate the mirror problem by only transmitting
the signature parts of a file, right?)


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140921205441.GA29763@fama

PPA security (was: Debian mirrors and MITM)

[W. Martin Borgert]

Quoting Jeremie Marguerie jere...@marguerie.org:

Thanks for bringing that issue! I feel the same way when I install a
packet from a non-official PPA.


Unfortunately, every package can do anything: pre-inst, post-inst,
pre-rm, post-rm run as root. If you don't trust a PPA the same way
you trust your OS vendor (Debian, Ubuntu or whoever), install only
in a VM or a container (not sure, whether a docker container is
considered safe enough, but chroot is not sufficient).

Alternatively, download the package, unpack it, remove maintainer
script or check them carefully, check for s-bits on binaries etc.
repack it and install. I'm probably missing more checks here.

While it would be nice to have sth. like less trusted sources and
allow their packages only certain kinds of install/de-install
operations (i.e. no maintainer scripts) etc., it's  hard to get
right and a broken solution would put users at risk.

Cheers


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140530204120.horde.zo1cetednp5glvdc16ay...@webmail.in-berlin.de

Re: md5 hashes used in security announcements

[W. Martin Borgert]

On 2008-10-25 07:09, Felipe Figueiredo wrote:
 Can anyone please explain why that long list of links and filenames is 
 interesting, or point to a link that does?

I assume, it's tradition from the times, when only few people
used apt-get and friends (and many years apt-get did not have
signature support). A pointer to a generic description for
people who don't want to/cannot use apt-get would be sufficient
nowadays. Could someone from the security team correct me?


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

Re: antivirus for webserver

[W. Martin Borgert]

On 2008-10-06 21:57, R. W. Rodolico wrote:
 And, install a good log summary program and read the results religiously.

I use visitors. Would you suggest another one?


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

Re: Fwd: Password leaks are security holes

[W. Martin Borgert]

On 2008-08-28 13:05, Johan Walles wrote:
 It's readable by anybody with physical access to the hardware.

If their have physical access to the hardware, auth.log would be
my least worry.

 That doesn't mean Debian should *help* root doing that in a default
 install.  Security by default, anybody?

Yes. But I fail to see, that this is not the case here.

 I can see a point in logging *valid* usernames.  Logging invalid
 usernames (which aren't unlikely to actually be passwords) is a
 security risk.

Sometimes, a user thinks their username is valid, and the system
thinks it is not. They call the system administrator and with
the help of auth.log they can find out what the problem is.

 [1] - http://www.finfacts.ie/irishfinancenews/article_1014326.shtml

It says Almost 4,000 Laptops lost or missing in Europe's major
airports every week. Let's assume their disks are encrypted,
which is very easy using the Debian Installer (since etch, IIRC?).

Note: I certainly typed in accidently a password for a login name
in the past and would not oppose a patch by you to (optionally!)
not log user names. But I fail to see a real problem here. After
all, most users make mistakes when it comes to e-mail (e.g.
sending confidential information to the wrong person or even a
publically archived mailing list etc.) Here I see much more
potential for problems than auth.log.


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

DNS and cats: Password leaks are security holes

[W. Martin Borgert]

On 2008-08-28 20:40, Simon Valiquette wrote:
 That's obviously true, but that doesn't cover the case when logs are  
 copied to a second system with sysadmins that doesn't have access to the  
 first server.  And if someone use the standard 514 syslog port instead of 
 using an SSL tunnel or the newer syslog-tls on port 601, well you get  
 cleartext password on the wire (yes, people sometime make stupid 
 mistakes).

I once typed a password accidently in address line of a web
browser, which popped up in the wrong moment. This resulted in a
DNS query for my password. I hereby declare it a security bug,
that the web browser tries to resolve my password! :~)

 Personally, I would prefer never to see password stored in clear text  
 anywhere, whatever the file permissions are.

We're talking here about a password that has been typed
accidently for other information. We're not talking about a
regular password store. If the password is good, nobody will
assume a password, but think, that a cat ran over the keyboard.


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

Re: Find installed contrib and non-free packages

[W. Martin Borgert]

On Thu, Jun 12, 2008 at 11:38:33AM +0200, Filip Husak wrote:
 I think the following command resolves your problem:

 for pkg in `dpkg -l | grep ii | awk '{print $2}'` ; do if [ `apt-cache
 show $pkg | grep 'contrib\|non-free' | wc -l` -ne 0 ]; then echo $pkg;
 fi; done

You should grep for ^Filename: pool/\(contrib\|non-free\)/ to
prevent false positives. And: Packages that have been installed
from non-Debian apt sources or via dpkg --install are missed.


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

Re: Find installed contrib and non-free packages

[W. Martin Borgert]

On Thu, Jun 12, 2008 at 12:27:12PM +0200, Vladislav Kurz wrote:
 1. remove contrib and non-free from /etc/apt/sources.list
 2. run dselect (update, select) and you will see all contrib and non-free 
 packages as obsolete/local packages. 

Good, because it will show other suspects as well. E.g. packages
from non-Debian apt sources, which are also unsupported
security-wise. I wonder how I can achieve the same using just
apt-get/apt-cache? I remember, that I once wrote a script using
python-apt to get this information, but the script is lost :~(


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

Re: Find installed contrib and non-free packages

[W. Martin Borgert]

On Fri, Jun 13, 2008 at 07:40:15AM +1000, Andrew Vaughan wrote:
 On Friday 13 June 2008 07:17, Andrew Vaughan wrote:
  In lenny
  $ aptitude search ~o
...
 Actually no need for aptitude,  
 $ apt-show-versions |grep No available version in archive$
 will do the job.

This is probably The solution. Both apt-show-versions and
aptitude are reasonable fast for the job. The shell script
posted elsewhere in this thread needs about forever and a bit.


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

Re: Frustration with randome number generator vuln and ssh

[W. Martin Borgert]

On Wed, Jun 04, 2008 at 02:37:38PM -0500, James Miller wrote:
 All I needed to do was run aptitude install libssl0.9.8=0.9.8c-4etch3  
...
 I have to admit, I _really_ need to learn aptitude, I'm kinda stuck in my 
 ways using apt-get and dselect.

I believe, that apt-get install package=version works as
well. Or: apt-get install package/distribution with
distribution = stable or testing or unstable. No need to switch
to aptitude, IMHO. But let dselect rest in peace :~)

(Another common aptitude advantage was its automatic handling of
orphaned packages, but apt-get does the same since some time.)


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

OT: apt-get (was: Frustration with randome number generator vuln and ssh)

[W. Martin Borgert]

On Wed, Jun 04, 2008 at 10:24:53PM +0200, yosh wrote:
 Sorry for hijacking the thread :)

 If I choose install a package from stable and there is a newer copy in  
 testing (which I'm using) apt-get will try to replace that package on  
 the next apt-get upgrade. Is there any way to counteract this?

Simple way: set the package on hold with dpkg --set-selections
Advanced way: apt-pinning, allows more fine-grained control


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