headers
Steven M. Bellovin | 15 Feb 2005 19:28

incompatibility between audit-packages and make-time checks

There's an incompatibility in how the vulnerability database is checked 
in pkgsrc Makefiles versus how it's checked in audit-packages.  This is 
showing up today with mozilla-gtk2; you can do a 'make install' and it 
will succeed, but audit-packages will flag it. 

The problem, I believe, is in the definition of a regular expression.  
The line causing trouble is this:

   mozilla{,-bin,-gtk2,-gtk2-bin}<=1.7.5           www-address-spoof       http://secunia.com/advisories/14154/

The check in 'make' is relying on awk and 'pkg_admin pmatch'; the check 
in audit-packages uses pkg_info to see if something matching that 
pattern is installed.  Somehow, they're producing different answers.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Permalink | Reply | 0 comments |
headers
Wolfgang S. Rupprecht | 15 Feb 2005 23:30

mozilla/firefox address spoof


It sounds like the address spoofing can be prevented by turning off
the IDN logic.  

* in the URL window type:  about:config
* in the new "Filter window" type: network.enableIDN
* in the main window click on the above variable
* in the main window, use the button-3 pull-down, select "toggle" 
     the value should turn from true to false.

Exit mozilla to write out the new prefs.js file.  (If mozilla crashes
before doing a graceful exit the changes won't be saved.)

Someone that understands the mozilla source tree might want to hunt
down this variable there and patch the defaults at the source.

-wolfgang
--

-- 
Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/
     Hate software patents?  Sign here: http://thankpoland.info/
Permalink | Reply | 0 comments |
headers
Daniel Carosone | 16 Feb 2005 01:22
Picon

Re: mozilla/firefox address spoof

On Tue, Feb 15, 2005 at 02:30:08PM -0800, Wolfgang S. Rupprecht wrote:
> 
> It sounds like the address spoofing can be prevented by turning off
> the IDN logic.  
> 
> * in the URL window type:  about:config
> * in the new "Filter window" type: network.enableIDN
> * in the main window click on the above variable
> * in the main window, use the button-3 pull-down, select "toggle" 
>      the value should turn from true to false.

This doesn't actually work, alas.  

Changing this setting works for the browser instance in which it was
set.  Quitting saves the preference, and it can be seen as 'false' in
new browsers, but the behaviour is as if it were 'true' until you
manually re-toggle the pref.  

--
Dan.
Permalink | Reply | 0 comments |
headers
Alistair Crooks | 16 Feb 2005 11:59

Re: incompatibility between audit-packages and make-time checks

On Tue, Feb 15, 2005 at 01:28:53PM -0500, Steven M. Bellovin wrote:
> There's an incompatibility in how the vulnerability database is checked 
> in pkgsrc Makefiles versus how it's checked in audit-packages.  This is 
> showing up today with mozilla-gtk2; you can do a 'make install' and it 
> will succeed, but audit-packages will flag it. 
> 
> The problem, I believe, is in the definition of a regular expression.  
> The line causing trouble is this:
> 
>    mozilla{,-bin,-gtk2,-gtk2-bin}<=1.7.5           www-address-spoof       http://secunia.com/advisories/14154/

The vulnerability database doesn't use a regular expression in the
sense of re_format(7) or POSIX regexps - it uses its own way of doing
it, such that ordering of version numbers can be checked. Hence the
csh-style alternates, and <=, <, >, >=.

> The check in 'make' is relying on awk and 'pkg_admin pmatch'; the check 
> in audit-packages uses pkg_info to see if something matching that 
> pattern is installed.  Somehow, they're producing different answers.

There's also a fundamental difference between the two checks, in that
the call via pkg_info (for the audit-packages case) is checking an
installed package version against the database.  The check in 'make'
at package build time can't do that, and so it does a "would this
match if it were installed?" style of check.  I thought that they used
the same code path (they do use the same basic matching routines), but
it's been years since I wrote them, and even then they were munged
around by someone else after that.

Having investigated further, I've located the problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alistair Crooks | 16 Feb 2005 15:06

Using multiple digest algorithms in pkgsrc

Following on from

	http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

I've made some modifications to bsd.pkg.mk so that a number of digest
algorithms can be specified for dist files and dist patches.  I have
kept the digests of our included patch files to be simply sha1 for
just now, since they are really meant to indicate whether a file has
changed, and are not used to guarantee file integrity - in short, if
someone can modify the patch file, they can modify the distinfo file
holding its information.

I have extended the DIGEST_ALGORITHM definition (which is set by ?=
in bsd.pkg.mk) to be a whitespace-separated list of algorithms which
are used in "makedistinfo" to generate the distinfo files.

The modifications produce distinfo files which look like this:

[14:00:06] agc <at> sys3 ...pkgsrc/misc/libutf 107 > cat distinfo 
$NetBSD: distinfo,v 1.3 2002/12/23 08:03:03 jmmv Exp $

SHA1 (libutf-2.10.tar.gz) = 8dd0f6873112deaa5b5bf2a0554e28f9d8d4ddda
RMD160 (libutf-2.10.tar.gz) = f7be9f311440fe68654ce0312e869dc6a94dc47f
Size (libutf-2.10.tar.gz) = 55099 bytes
SHA1 (patch-aa) = 13ed8cf7d011e10f207d0d95a9d033b41251be44
SHA1 (patch-ab) = 993fa48a26c1111fbbcd5464eae1b6ea07cb4ffc
[14:00:09] agc <at> sys3 ...pkgsrc/misc/libutf 108 >

and produce the following output:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven M. Bellovin | 16 Feb 2005 15:21

Re: incompatibility between audit-packages and make-time checks

In message <20050216105942.GA5957 <at> nef.pbox.org>, Alistair Crooks writes:

>
>Having investigated further, I've located the problem.
>
>bsd.pkg.mk does the checks for the vulnerable package in a target called
>check-vulnerable. It is basically an invocation of awk:
>
>               ${SETENV} PKGNAME="${PKGNAME}"                          \
>                          PKGBASE="${PKGBASE}"                          \
>                        ${AWK} '/^$$/ { next }                          \ 
>                                /^#.*/ { next }                         \ 
>                                $$1 !~ ENVIRON["PKGBASE"] { next }      \ 
>                                { s = sprintf("${PKG_ADMIN} pmatch \"%s\" %s &
>& ${ECHO} \"*** WARNING - %s vulnerability in %s - see %s for more information
> ***\"", $$1, ENVIRON["PKGNAME"], $$2, ENV
>IRON["PKGNAME"], $$3); system(s); }' < ${PKGVULNDIR}/pkg-vulnerabilities || ${
>FALSE}; \
>
>The problem area is the line which is used to try to speed up the search by
>ignoring packages which don't match the basename of the package (the package
>name without any version suffix).
>
>	$$1 !~ ENVIRON["PKGBASE"] { next }
>
>If this line is removed, the check in www/mozilla-gtk2 will work fine, at
>the cost of some more cycles at package build time. With caches filled,
>the timings are as follows:
>
>[10:52:31] agc <at> sys3 ...pkgsrc/www/mozilla-gtk2 56 > time make check-vulnerable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan RP | 16 Feb 2005 15:55

Re: Using multiple digest algorithms in pkgsrc

On Wed, 16 Feb 2005 14:06:55 +0000
Alistair Crooks <agc <at> pkgsrc.org> wrote:

> Following on from
> 
> 	http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
> 
> I've made some modifications to bsd.pkg.mk so that a number of digest
> algorithms can be specified for dist files and dist patches.  I have
> kept the digests of our included patch files to be simply sha1 for
> just now, since they are really meant to indicate whether a file has
> changed, and are not used to guarantee file integrity - in short, if
> someone can modify the patch file, they can modify the distinfo file
> holding its information.
> 
> I have extended the DIGEST_ALGORITHM definition (which is set by ?=
> in bsd.pkg.mk) to be a whitespace-separated list of algorithms which
> are used in "makedistinfo" to generate the distinfo files.

Really cool!
Permalink | Reply | 0 comments |
headers
Jason Thorpe | 27 Feb 2005 17:10

Regarding the use of pam_ssh

CC'ing to tech-security because I think it warrants discussion.

On Feb 27, 2005, at 1:56 AM, John Nemeth wrote:

>      I am working on creating a couple of missing files (pppd and
> racoon).  I noticed that during this cleanup you nuked pam_ssh from the
> auth section of several files, although it is in the new
> display_manager file.  I was just wondering why this was done?

I nuked it from services where the ssh passphrase could be compromised 
by being sent over an unencrypted channel.

I have similar misgivings about pam_krb5 and certain protocols.

Anyway, pam_ssh for a display manager is perfectly fine, since you're 
(almost certainly) sitting at a console in that case.

-- thorpej
Permalink | Reply | 8 comments |
headers
John Nemeth | 27 Feb 2005 20:05
Picon
Favicon

Re: Regarding the use of pam_ssh

On Jul 20,  2:45am, Jason Thorpe wrote:
} On Feb 27, 2005, at 1:56 AM, John Nemeth wrote:
} 
} >      I am working on creating a couple of missing files (pppd and
} > racoon).  I noticed that during this cleanup you nuked pam_ssh from the
} > auth section of several files, although it is in the new
} > display_manager file.  I was just wondering why this was done?
} 
} I nuked it from services where the ssh passphrase could be compromised 
} by being sent over an unencrypted channel.

     Okay, this is understandable.

} I have similar misgivings about pam_krb5 and certain protocols.

     Yes, this should probably be treated the same as pam_ssh.
However, doing so, may cause surprising changes in the way
authentication works for those certain protocols.

} Anyway, pam_ssh for a display manager is perfectly fine, since you're 
} (almost certainly) sitting at a console in that case.

     I must be the exception since my primary use of display managers
is for managing real live X terminals (NCD).

     Based on this, pppd should be fine, since it would primarily be
used for modems that are directly attached to the system (modems
attached to terminal servers would usually use RADIUS).  How about
racoon?  I don't know if the passwords it sends are sent over an
encrypted channel.  Since login would be used primarily by getty runing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Barrett | 27 Feb 2005 20:12
Gravatar

Re: Regarding the use of pam_ssh

On Sun, 27 Feb 2005, Jason Thorpe wrote:
> I nuked it from services where the ssh passphrase could be compromised 
> by being sent over an unencrypted channel.
> 
> I have similar misgivings about pam_krb5 and certain protocols.
> 
> Anyway, pam_ssh for a display manager is perfectly fine, since you're 
> (almost certainly) sitting at a console in that case.

I think that pam_ssh should not be enabled by default for any
services, for too reasons:

1. People sometimes use weak ssh passphrases, under the assumption that
   an opponent with the passphrase will not be able to do anything
   without also having access to a copy of the encrypted private key.
   pam_ssh changes this so that mere possession of the passphrase
   allows access to the account, which in turn allows access to the
   encrypted private key, which allows the opponent to make outgoing
   SSH connections as the user.  In other words, pam_ssh changes
   the security model for SSH passphrases from "need passphrase and
   encrypted private key to do anything" to "need passphrase to do
   anything".

2. As Jason said, the passphrase may be sent in cleartext over
   easily-snoopable channels.

Some people might have a use for pam_ssh, and they should be allowed to
use it, but the security implications should be better documented, and
it should not be enabled by default.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane