Re: Which Debian packages leak information to the network?

[Paul Wise]

On Thu, May 19, 2016 at 7:56 AM, georg wrote:
> On 16-05-18 16:54:27, Holger Levsen wrote:
>> gnome-calculator contacts a web page/service with currency exchange
>> information *on every start*,
>
> Is this "publicly" known? Is this discussed with the upstream devs?

https://bugzilla.gnome.org/show_bug.cgi?id=741828

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian SHA-1 deprecation

[Paul Wise]

On Wed, May 18, 2016 at 9:20 PM, Daniel Pocock wrote:

> Can anybody comment on how Debian users will be impacted by SHA-1
> deprecation?

There is some info related to that in these two wiki pages:

https://wiki.debian.org/SHA-1
https://wiki.debian.org/Teams/Apt/Sha1Removal

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Which Debian packages leak information to the network?

[ge...@riseup.net]

On 16-05-18 16:54:27, Holger Levsen wrote:
> gnome-calculator contacts a web page/service with currency exchange
> information *on every start*,

Is this "publicly" known? Is this discussed with the upstream devs?


signature.asc
Description: Digital signature

Re: debcheckroot v1.0 released

[Bottom Post]

On Wed, May 18, 2016 at 06:07:00PM +0200, Elmar Stellnberger wrote:
>   Well; you are right Patrick; [ ... snip ... ]

Other thing that Patrick does right,
is making it possible to read in discussion order


Please reply below the text

Re: Which Debian packages leak information to the network?

[Holger Levsen]

On Wed, May 18, 2016 at 06:33:52PM +0200, Jakub Wilk wrote:
> Could you explain how any of these tools leak any information "without a
> user's consent/expectation"?

gnome-calculator contacts a web page/service with currency exchange
information *on every start*, I think that's a good example of the kind
of programs Patrick is looking for.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Which Debian packages leak information to the network?

[Jakub Wilk]

* Patrick Schleizer , 2016-05-18, 15:50:
we are a privacy-centric distro based on Debian and wanted to know what 
Debian packages leak information about the system to the network 
without a user's consent/expectation.


As documented on the page below, a system's security also depends on 
avoiding leaking any identifiable information to network adversaries by 
accident.


python-requests used to include kernel version number in User-Agent. 
(And also Python version, but that's less exciting.) This was fixed 
upstream in 2.8.0:

https://github.com/kennethreitz/requests/issues/2785

pip leaks even more stuff in U-A:
$ python -c 'import pip; print pip.download.user_agent()'
pip/8.1.2 
{"cpu":"x86_64","distro":{"libc":{"lib":"glibc","version":"2.7"},"name":"debian","version":"stretch/sid"},"implementation":{"name":"CPython","version":"2.7.11+"},"installer":{"name":"pip","version":"8.1.2"},"openssl_version":"OpenSSL
 1.0.2h  3 May 2016","python":"2.7.11+","system":{"name":"Linux","release":"4.5.0-2-amd64"}}

(As a side note, I don't think this is RFC-2616-compliant...)


Popcon, bts, wnpp-check are the noted examples


Could you explain how any of these tools leak any information "without a 
user's consent/expectation"?


--
Jakub Wilk

Re: debcheckroot v1.0 released

[Elmar Stellnberger]

  Well; you are right Patrick; perhaps I should do something to awake 
debcheckroot from its slumber! If I am not the one who can build a 
respective infrastructure around the project (i.e. checksums for all 
Debian packages) and develop the code forth then someone else would do 
it as there seems to be sufficient interest in the project.


  The first step towards doing so would be to give debcheckroot a 
correct license. I have been thinking of C-FSL-v0.9->1.0, a license we 
would have to discuss on debian-legal, first. I would really like to 
have a universal license that fits all of my projects, first. If there 
should in deed be a non-refittable problem with it I am ready to retract 
it in favour of a BSD-like license (however for debcheckroot, only).



Am 2016-05-18 um 17:29 schrieb Patrick Schleizer:

Elmar Stellnberger:

Here is a wishlist of mine:

- put your code in git source code management


  That would be a good starting point. Nonetheless I would like to keep 
the git repository hosted somewhere on my own page (currently: 
https://www.elstel.org/debcheckroot) as it already is in support of 
DNSSEC/DANE. Furthermore someone would have to assist me in setting up 
write access for such a git-repository (up to now I have only been using 
git offline). Perhaps something to discuss on another debian mailing list.




- create a debcheckroot Debian package


... that was already done some time ago; though the license had hampered 
approval of the package.




- upload that Debian package to official Debian repository (that would
simplify creation of a Live DVD or Live USB with debcheckroot a lot; and
get debcheckroot from a safer location; helps with publicity)

- doesn't debcheckroot perfectly fit with the Debian reproducible team?
They might be interested in to help with packaging and sponsoring
upload. Please consider getting in touch with them.


Thx for the reference; I will look for them as soon as the licensing and 
the issue about a secure git repository would be resolved.




Cheers,
Patrick

Which Debian packages leak information to the network?

[Patrick Schleizer]

Hello we are a privacy-centric distro based on Debian and wanted to know
what Debian packages leak information about the system to the network
without a user's consent/expectation.

As documented on the page below, a system's security also depends on
avoiding leaking any identifiable information to network adversaries by
accident. Popcon, bts, wnpp-check are the noted examples so far (which
we blacklist in our distro). Please help notify us of any other such
packages.

https://wiki.debian.org/TorifyDebianServices

Re: debcheckroot v1.0 released

[Patrick Schleizer]

Elmar Stellnberger:
> Dear Debian-Security
> 
>   Having just released debcheckroot I wanna shortly present you my new tool:
> It was originally designed as a replacement for debsums and has the following 
> qualities:
> * full support of Debian repos reading /etc/[apt/]sources.list to fetch 
> checksums online
> * it can check a Debian installation remotely from any Unix-like system just 
> requiring perl, gzip, bzip2 and tar
> * it does not require a chroot into or any tools of the installation to be 
> checked; 
>   debcheckroot is thus the better choice when it comes to security (chroots 
> may infect the freshly booted system); 
>   The checkroot family of programs has already proven to spot various 
> rootkits not detected by chkrootkit and rkhunter
> * usage of checksums in the package header by default rather than locally 
> stored ones (insecure if not backed up on f.i. an USB-stick); fast unpacking 
> on the fly into memory without the creation of temporary files
> * nicely formatted output into files for later analysis
> … and all of that in just a 930 lines of code.
> 
> Though debcheckroot is currently still licensed under S-FSL I am ready to 
> re-publish under any license you like
> if you can at least promise me to maintain the necessary support 
> infrastructure for it:
> * sha256sums rather than the bit old fashioned md5sums
> * checksums for all packages in the core distro (some are still missing 
> md5sums)
> i.e. we would have to update debhelper to create shasums in addition to 
> md5sums and enable this for all packages
> 

Here is a wishlist of mine:

- put your code in git source code management

- create a debcheckroot Debian package

- upload that Debian package to official Debian repository (that would
simplify creation of a Live DVD or Live USB with debcheckroot a lot; and
get debcheckroot from a safer location; helps with publicity)

- doesn't debcheckroot perfectly fit with the Debian reproducible team?
They might be interested in to help with packaging and sponsoring
upload. Please consider getting in touch with them.

Cheers,
Patrick

Re: Debian SHA-1 deprecation

[Elmar Stellnberger]

Am 2016-05-18 um 15:20 schrieb Daniel Pocock:



Can anybody comment on how Debian users will be impacted by SHA-1
deprecation?

In particular:

- will libraries like OpenSSL and GnuTLS continue to support it in
stretch and beyond?

- will web servers like Apache support it in server certificates or
certificate chains?

- will web servers and other applications accept client certificates
containing SHA-1 hashes?

- if support for SHA-1 is being removed or disabled by default, will it
also be disabled in security updates to jessie and wheezy LTS?



  Besides these issues; has anyone ever thought of deprecating md5sum-s 
in package headers and using sha256sums instead? That would be of great 
help for tools like debsums or https://www.elstel.org/debcheckroot.

Problems in https://www.debian.org/doc/manuals/securing-debian-howto

[Richard Owlett]

1. 
https://www.debian.org/doc/manuals/securing-debian-howto/ch-automatic-harden.en.html#s6.2 
describes Bastille Linux which is no longer in Debian.


2. Should there be information on AppArmor and SELinux (other 
than footnote 66]?

Debian SHA-1 deprecation

[Daniel Pocock]

Can anybody comment on how Debian users will be impacted by SHA-1
deprecation?

In particular:

- will libraries like OpenSSL and GnuTLS continue to support it in
stretch and beyond?

- will web servers like Apache support it in server certificates or
certificate chains?

- will web servers and other applications accept client certificates
containing SHA-1 hashes?

- if support for SHA-1 is being removed or disabled by default, will it
also be disabled in security updates to jessie and wheezy LTS?

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

[Hans-Christoph Steiner]

The Android SDK is really probably more like Eclipse.  About 5 years of
support, they are still maintaining Android 2.3.3 to some degree and
that's at least 5 years old.
https://android.stackexchange.com/a/84816

Also, the security profile is relatively low risk for the Android SDK in
general:

* mostly various user utilities
* no setuid or special permissions
* only one daemon-like thing, adb, with no net access by default
* a good chunk is just files on the filesystem (e.g. libs for Android apps)

.hc

Hans-Christoph Steiner:
> 
> BoringSSL is just a part of the Android SDK.  It has an unstable API
> because it is only the C backing to a single Java library called
> conscrypt.  That library is in turn only used as part of the Android
> SDK.  Using the upstream build system, all of the source code is checked
> out at once from many git repos, and built together.  Compare this to
> Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of
> source code that are organized internally as "libraries".
> 
> We are packaging these chunks separately because we believe it will make
> it easier to maintain.  Security updates can happen only in the
> particular package rather than having to build the whole Android SDK
> together as one giant source tree.
> 
> Upstream is already good at providing security fixes for all of the
> various bits, and they maintain quite a few stable releases in parallel.
>  Security maintenance for the Android SDK packages will mostly be a
> matter of just including any new patch versions (i.e. 6.0.1_r14 vs
> 6.0.1_r15).
> 
> .hc
> 
> Ralph Sanchez:
>> My opinion might not mean much, but as a user, I agree with this. If
>> i'm installing from the stable depository, we expect certain things
>> from packages there and everything must be held to those guidelines.
>> And mostly if we are using it from unstable, we are hoping to see it
>> evolve into being put into the stable form, not just stagnate or we
>> won't use it, which is bad for the both the user (losing out on
>> promising programs) and the company (losing out on users), i think
>>
>> On Tue, May 17, 2016 at 11:27 AM, Michael Stone  wrote:
>>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote:

 BoringSSL is also free software, as long as there are maintainers who
 are willing to spend time on it, I think it has rights to exist in
 Debian. Well I have been contributing to Debian for not long, so
 please point me out my mistakes. :)
>>>
>>>
>>> The question is, "who does the security updates for the package 5 years from
>>> now". As a general rule, we don't allow private embedded copies of libraries
>>> because then a security update for a library means chasing down and fixing
>>> any number of copies. (In historic terms, this was a huge issue, for
>>> example, with zlib bugs.) On top of that, if the upstream says flat-out that
>>> it's an unstable API, putting it into a debian release seems like a bad
>>> idea. Putting it unstable and never letting it make it to stable is a
>>> possibility, but the point of unstable is to eventually get packages into a
>>> released version so that seems somewhat an abuse of the system. If it's
>>> really a standalone component that's expected to change a lot and not
>>> interact with anything else in debian, then putting it in an external
>>> repository seems like a better fit.
>>>
>>> Mike Stone
>>>
>>
> 

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

[Hans-Christoph Steiner]

BoringSSL is just a part of the Android SDK.  It has an unstable API
because it is only the C backing to a single Java library called
conscrypt.  That library is in turn only used as part of the Android
SDK.  Using the upstream build system, all of the source code is checked
out at once from many git repos, and built together.  Compare this to
Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of
source code that are organized internally as "libraries".

We are packaging these chunks separately because we believe it will make
it easier to maintain.  Security updates can happen only in the
particular package rather than having to build the whole Android SDK
together as one giant source tree.

Upstream is already good at providing security fixes for all of the
various bits, and they maintain quite a few stable releases in parallel.
 Security maintenance for the Android SDK packages will mostly be a
matter of just including any new patch versions (i.e. 6.0.1_r14 vs
6.0.1_r15).

.hc

Ralph Sanchez:
> My opinion might not mean much, but as a user, I agree with this. If
> i'm installing from the stable depository, we expect certain things
> from packages there and everything must be held to those guidelines.
> And mostly if we are using it from unstable, we are hoping to see it
> evolve into being put into the stable form, not just stagnate or we
> won't use it, which is bad for the both the user (losing out on
> promising programs) and the company (losing out on users), i think
> 
> On Tue, May 17, 2016 at 11:27 AM, Michael Stone  wrote:
>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote:
>>>
>>> BoringSSL is also free software, as long as there are maintainers who
>>> are willing to spend time on it, I think it has rights to exist in
>>> Debian. Well I have been contributing to Debian for not long, so
>>> please point me out my mistakes. :)
>>
>>
>> The question is, "who does the security updates for the package 5 years from
>> now". As a general rule, we don't allow private embedded copies of libraries
>> because then a security update for a library means chasing down and fixing
>> any number of copies. (In historic terms, this was a huge issue, for
>> example, with zlib bugs.) On top of that, if the upstream says flat-out that
>> it's an unstable API, putting it into a debian release seems like a bad
>> idea. Putting it unstable and never letting it make it to stable is a
>> possibility, but the point of unstable is to eventually get packages into a
>> released version so that seems somewhat an abuse of the system. If it's
>> really a standalone component that's expected to change a lot and not
>> interact with anything else in debian, then putting it in an external
>> repository seems like a better fit.
>>
>> Mike Stone
>>
> 

External check

[Raphael Geissert]

CVE-2015-4116: TODO: check
CVE-2016-2803: RESERVED
--
The output might be a bit terse, but the above ids are known elsewhere,
check the references in the tracker. The second part indicates the status
of that id in the tracker at the moment the script was run.