Bug#1029319: arp-scan: should be built with libcap support
Hi Marcos, I'm the upstream author. I broadly agree with Sven, and think that it's best to build with libcap capabilities support if possible because it increases security. arp-scan's needs are similar to ping: the only capability it needs on Linux is CAP_NET_RAW, and it only needs to enable that for the brief period when it opens the network socket. I gave arp-scan the option to be capabilities aware to fulfil the principle of least privilege. > arp-scan is an admin command. It is installed (by default) in > /usr/sbin/, this directory is not in the $PATH of a normal user. I'm not sure what exactly we mean by an "admin command". arp-scan can be used for sysadmin, but it also has other use cases. Some I know of are: auditing network equipment, pentesters generating hosts lists, services that run arp-scan regularly and log to a database. Some Debian users may be using it outside sysadmin roles. It's worth mentioning that capabilities support was a reqested feature: https://github.com/royhills/arp-scan/issues/21 Thanks, Roy
Bug#755464: arp-scan: does not honour "mac-vendor.txt" properly
I believe this issue is fixed in the latest upstream version of arp-scan which is git tag 1.9.8 on github. mac-vendor.txt can now accept mac addresses as normal mac addresses with ":" or "-" separators and with the alphabetic characters in either upper or lower case. This allows you to paste mac addresses from arp-scan or ifconfig directly into mac.vendor.txt. Note that there is now an IEEE oui assignment for 90:18:7c, so you would need to add a more specific entry to mac-vendor.txt, e.g. 90:18:7c:48:dd:dbVendor Details Thanks. Roy --
Bug#682342: netcfg DHCP information handling regression between Lenny and Squeeze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: netcfg Version: 1.59 I'm using PXE boot with network preseeding to perform automated Debian installations with Lenny, Squeeze and Wheezy. With Lenny, netcfg used the DHCP options domain-name, domain-name-servers, and ntp-servers. With Squeeze and Wheezy, these options seem to be ignored. I have the following in my DHCP configuration file, dhcpd.conf: option domain-name training.nta-monitor.com; option domain-name-servers ns0.training.nta-monitor.com; option ntp-servers ntp0.training.nta-monitor.com; And I'm using the following boot parameters in the PXE configuration file: append vga=normal initrd=debian/lenny/i386/initrd.gz hostname=unassigned domain=unassigned netcfg/no_default_route=true auto=true url=http://10.0.57.1/debian/d-i/lenny/preseed.cfg DEBCONF_DEBUG=5 For Lenny, this works fine. In particular the domain name gets set from the DHCP domain-name option, the DNS servers get set from domain-name-servers, and the system sets the time from the NTP server specified by the ntp-servers option. For Squeeze, these boot parameters (appropriately changed to use the Squeeze preseed URL) result in the domain name getting set to unassigned, the installer prompting for the DNS servers, and the system trying to use the default Debian NTP servers (and failing because I'm behind a proxy with no direct Internet access). Wheezy shows the same behaviour as Squeeze. I can specify these parameters by adding the appropriate additional parameters to the boot options, but this is not ideal as I'd like to store the information in the DHCP configuration so it's just in one place. I think this is a regression in netcfg some time between Lenny and Squeeze. I notice the following changelog entry for netcfg 1.48: * Refactor dhcp configuration code. Could that be the culprit I wonder? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlALDrQACgkQy4enOlZ7nzpw6QCeOyTYnCafj0eIpkSB+dnBhKWB k80An34LxUlU599Sxprp1395LPgUyTVm =6HUK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#401175: Could offer to set a label on swap partitions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The installer still doesn't support swap labels as of Debian Wheezy.
As persistent device naming using label or UUID is now preferred over
the traditional
bus names for disks, this would be a useful addition to partman.
I've tried using this partman expert recipe fragment in a preseed file:
300 400 500 linux-swap\
method{ swap }\
label{ swap } \
format{ } \
But it seems that the label directive is ignored for swap, because
this doesn't label the swap partition.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAJR+AACgkQy4enOlZ7nzrCxQCgyp02phOKf0XUlPpkACLWJzvO
SW0AoMy1/H/SymKOnBj2OrtxoZTbbmjn
=xhOO
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679628: libxcrypt1: crypt_blowfish doesn't properly handle 8-bit characters (CVE-2011-2483)
Package: libxcrypt1
Version: 1:2.4-1
Severity: normal
I think the crypt_blowfish implementation in libxcrypt 2.4-1 has the sign
extension bug detailed in CVE-2011-2483.
Full details of this bug are at: http://seclists.org/oss-sec/2011/q2/632
crypt_blowfish.c in the libxcrypt source package contains the following
code, which indicates that it's affected by this bug:
for (j = 0; j 4; j++) {
tmp = 8;
tmp |= *ptr;
if (!*ptr) ptr = key; else ptr++;
}
The problem is in the statement tmp |= *ptr, where ptr is a plain
char. This should be cast to an unsigned char, e.g.
tmp |= (unsigned char)*ptr
Upgrading to the latest upstream source should fix this bug.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libxcrypt1 depends on:
ii libc6 2.13-33
libxcrypt1 recommends no packages.
libxcrypt1 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526658: rsyslogd manpage says pid file is /var/run/syslogd.pid, but it is really /var/run/rsyslogd.pid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: rsyslog Version: 3.18.6-4 Severity: normal The manpage for rsyslogd says the daemon's pid file is /var/run/syslogd.pid, but it is actually /var/run/rsyslogd.pid. - From the rsyslogd(8) manpage: Rsyslogd reacts to a set of signals. You may easily send a signal to rsyslogd using the following: kill -SIGNAL $(cat /var/run/syslogd.pid) Note that -SIGNAL must be replaced with the actual signal you are try‐ ing to send, e.g. with HUP. So it then becomes: kill -HUP $(cat /var/run/syslogd.pid) Observed on a Debian lenny system: r...@debian-lenny:/var/log$ ls -l /var/run/*syslog* - -rw-r--r-- 1 root root 5 2009-05-02 16:04 /var/run/rsyslogd.pid I actually think that it would be better for rsyslogd to use /var/run/syslogd.pid for its pid file, as that would be compatible with scripts written for the old sysklogd that used things like: kill -HUP `cat /var/run/syslogd.pid` To force the daemon to reload its config files. But whatever the pidfile's name, the manpage should be consistent with the actual behaviour. I'm running Debian Lenny on i386 with kernel 2.6.26-2-686. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ/GS0y4enOlZ7nzoRAiBuAKCfC9qMQhFuRbpr09ZV1N+HGjXy0QCg7zVV l/zHLYN+JApVKaJre0LzUHY= =/zjC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481296: Please coordinate the oui.txt file at some common shared place
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, I don't have any problems changing arp-scan to support central OUI files. Here are my thoughts: arp-scan uses autoconf/automake and by default looks for the MAC/Vendor mapping files in $(pkgdatadir). It would be simple to add an autoconf option to specify a different default location, which could be used in the debian build. arp-scan uses three MAC/Vendor mapping files: the IEEE OUI file (ieee-oui.txt), the IEEE IAB file (ieee-iab.txt) and the custom mapping file (mac-vendor.txt). I can see that the IEEE OUI and IAB files could be useful for other packages. I guess the custom mapping file may also be useful, and could be a central place to put custom MAC/Vendor mappings that are not present in either of the IEEE files. The files used by arp-scan are simplified versions of those on the IEEE website. These simplified versions are easier to parse and also take up less space. I suspect that most programs that require MAC/Vendor mappings could use these simplified file formats, but some may be better off with the original IEEE format files. I guess that the central files would be split into a separate Debian package that arp-scan would depend upon. I suppose this package could be put into debian-volatile to allow regular updates. However, the big question is whether it is worth doing. The data concerned is less than a megabyte, and other packages could make use of the get-oui and get-iab Perl scripts if they want to maintain their own lists. Please let me know if you'd like me to add a configure option to enable the default location for the MAC/Vendor mapping files to be changed. Roy Hills Tim Brown wrote: | Guys, | | As maintainer of arp-scan I recently received a bug report for this packaging | asking for oui.txt to be centrally maintained and shared between all packages | that use it. I have copied you in as you're the folk responsible for other | such packages as well as the upstream developer of arp-scan itself. | | The submitter would like to see something such as update-pciids which could be | shared between all of us. If you examine arp-scan you will notice it has two | scripts, get-iab and get-oui which would largely (with some hacking provide | the required functionality), would you be interested in making this feature | request happen? | | Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIOZBpy4enOlZ7nzoRAjJqAJ9dqIIKDdUALA1tZmyOdlTSBlCFPgCeL2rA 4Ww1KQnIxfdZ/9AWJHn7DIU= =C+zU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370440: onak dumps core when run with insufficient privileges
Package: onak Version: 0.3.1-1 If I run onak dump with insufficient privileges to read the database files in /var/lib/onak, it gets a SIGSEGV and dumps core: [EMAIL PROTECTED] [508]$ onak dump [05/06/2006 10:29:53] onak[30499]: Couldn't open logfile: /var/log/onak.log [05/06/2006 10:29:53] onak[30499]: Error opening db environment: /var/lib/onak (Permission denied) Segmentation fault (core dumped) An strace shows: time(NULL) = 1149500125 getpid()= 31120 write(2, [05/06/2006 10:35:25] onak[31120..., 35[05/06/2006 10:35:25] onak[31120]: ) = 35 write(2, Error opening db environment: /v..., 63Error opening db environment: /var/lib/onak (Permission denied)) = 63 write(2, \n, 1 ) = 1 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV (core dumped) +++ So it doesn't look like the SEGV is being caused by a syscall. If I run onak with sufficient privileges (e.g. as root), then there is no problem. This issue does not stop onak from working, it's just ugly. I'm running onak on Debian sarge on i386 with 2.6.15.7 kernel. -- Roy HillsTel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: [EMAIL PROTECTED] Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337973: Only libpcap0.7-dev provides libpcap-dev, libpcap0.8-dev does not
Package: libpcap-dev Version: 0.7.2-7 Some sarge packages have build-depends against libpcap-dev. Nmap and xprobe are two examples that I've found, although there may be others. There are two versions of the libpcap development package in sarge: libpcap0.7-dev and libpcap0.8-dev. libpcap-dev depends on libpcap0.7-dev only; libpcap0.8-dev will not satisfy the dependency. It's not possible to install both libpcap0.7-dev and libpcap0.8-dev because they conflict. Therefore, if you need to install libpcap-dev on a system which already has libpcap0.8-dev, this will end up downgrading the pcap development package from 0.8 to 0.7. I found that, in practice, the two packages I've tried compile and run without problems using libpcap0.8-dev (at least in my environment). I'm not totally sure what the problem is here, or who's responsibility it is. However, I think that it boils down to one of the following: 1. libpcap-dev should be removed, and bugs should be filed against nmap, xprobe and any other packages that have a build-depends against it; 2. libpcap-dev should depend on either libpcap0.7-dev or libpcap0.8-dev; 3. If there is a major incompatibility between 0.7 and 0.8, then it should be documented somewhere; or 4. If there is no compatibility problem, why can we not standardise on one version of libpcap? I'm running Debian 3.1 (sarge) on i386 with 2.6 kernel. I have the following libpcap packages installed: # dpkg -l | grep pcap ii libpcap0.7 0.7.2-7System interface for user-level packet captu ii libpcap0.8 0.8.3-5System interface for user-level packet captu ii libpcap0.8-dev 0.8.3-5Development library and header files for lib Regards, Roy Hills -- Roy HillsTel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: [EMAIL PROTECTED] Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337231: amap install fails if it cannot connect to www.thc.org; ignores http_proxy setting
Package: amap Version: 4.8-1 When installing amap, the post-installation script attempts to connect to www.thc.org to update the fingerprints. If the connection fails for any reason, the installation fails. In addition, the script does not attempt to the use HTTP proxy defined in the http_proxy environment variable. Here's an example installation of amap on a system which doesn't have a direct Internet connection, but can access the Internet via a proxy which is defined in http_proxy: Setting up amap (4.8-1) ... Upgrading trigger, response and rpc files ... Running Online Update for fingerprints, connecting to www.thc.org/thc-amap Error: could not connect to host: www.thc.org dpkg: error processing amap (--configure): subprocess post-installation script returned error exit status 255 Setting up agrep (2.04-3) ... Errors were encountered while processing: amap E: Sub-process /usr/bin/dpkg returned an error code (1) I suggest that the script should use http_proxy if it is defined, as this is standard practice. Also, a failure to download the fingerprints should not be a fatal error - it should just install the latest copy that was included in the package. I'm running Debian 3.1 (sarge) on i386 with 2.6 kernel. Regards, Roy Hills -- Roy HillsTel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: [EMAIL PROTECTED] Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334327: Underquoted definition in ucd-snmp.m4
Package: libsnmp4.2-dev Version: 4.2.5-5 automake1.9 gives the following warning for ucd-snmp.m4: [EMAIL PROTECTED] [507]$ aclocal /usr/share/aclocal/ucd-snmp.m4:12: warning: underquoted definition of AM_PATH_UCDSNMP run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal The offending M4 code reads: AC_DEFUN(AM_PATH_UCDSNMP, According to automake rules, AM_PATH_UCDSNMP should be quoted using square brackets. So line 12 should read: AC_DEFUN([AM_PATH_UCDSNMP], These new quoting rules were introduced around the time of Automake 1.8 IIRC. I'm running Debian sarge on an IA32 system. Packages: ii libsnmp4.2-dev 4.2.5-5NET SNMP (Simple Network Management Protocol ii libsnmp4.2 4.2.5-5NET SNMP (Simple Network Management Protocol ii automake1.91.9.5-1A tool for generating GNU Standards-complian ii autoconf 2.59a-3automatic configure script builder Regards, Roy Hills -- Roy HillsTel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: [EMAIL PROTECTED] Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329192: nullmailer ignores permanent SMTP errors
Package: nullmailer Version: 1.00RC7-22 I'm running nullmailer on debian sarge on many systems. They all use a central machine, running Sendmail 8.13.4-3 as their mail relay. I find that nullmailer will keep re-trying a message despite receiving a permanent SMTP error from the mail relay. For example, if I send an email to a non-existent user with: $ echo test | mailx -s Bad Address Test -v [EMAIL PROTECTED] This mail is shown in nullmailer's queue as: $ mailq 2005-09-20 11:06:13 328 bytes On the central mail server, we see that nullmailer is continually trying to send to the non-existent user every minute: Sep 20 11:06:13 mercury mta-daemon[22077]: j8KA6DrS022077: [EMAIL PROTECTED]... User unknown Sep 20 11:06:13 mercury mta-daemon[22081]: j8KA6DIu022081: [EMAIL PROTECTED]... User unknown Sep 20 11:07:13 mercury mta-daemon[22097]: j8KA7DHj022097: [EMAIL PROTECTED]... User unknown Sep 20 11:08:13 mercury mta-daemon[22277]: j8KA8DqD022277: [EMAIL PROTECTED]... User unknown Sep 20 11:09:13 mercury mta-daemon[22938]: j8KA9DTI022938: [EMAIL PROTECTED]... User unknown Sep 20 11:10:13 mercury mta-daemon[23092]: j8KAADXJ023092: [EMAIL PROTECTED]... User unknown Sep 20 11:11:13 mercury mta-daemon[23103]: j8KABD9X023103: [EMAIL PROTECTED]... User unknown Sep 20 11:12:13 mercury mta-daemon[23138]: j8KACDUM023138: [EMAIL PROTECTED]... User unknown Sniffing an SMTP exchange shows the following ( means data from the mail server, and means data to the mail server): TCP Handshake 220 mercury ESMTP Ready HELO helium.nta-monitor.com 250 mercury.nta-monitor.com Hello argon.nta-monitor.com [192.168.124.7], pleased to meet you MAIL FROM:[EMAIL PROTECTED] 250 2.1.0 [EMAIL PROTECTED]... Sender ok RCPT TO:[EMAIL PROTECTED] 550 5.1.1 [EMAIL PROTECTED]... User unknown TCP Closedown There are three issues here, from most to least serious: a) nullmailer is ignoring the 550 permanent SMTP error, and is re-trying the message later; b) The message never appears to time out from the queue - I've seen messages that are months old still queued; and c) nullmailer closes the TCP connection without sending a QUIT. Regards, Roy Hills -- Roy HillsTel: +44 1634 721855 NTA Monitor Ltd FAX: +44 1634 721844 14 Ashford House, Beaufort Court, Medway City Estate, Email: [EMAIL PROTECTED] Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318452: pam_limits.so capabilities support is broken
Package: libpam-modules
Version: 0.76-22
The support for Linux capabilities in pam_limits.so is broken. The source
code for this library, pam_limits.c, contains support for capabilities, but
some unrelated code in the same source file prevents it from working.
If I add the following line to /etc/security/limits.conf:
xxx - capabilitiesCAP_NET_BIND_SERVICE+eip
I get the following error recorded in syslog when logging in as user xxx:
Jul 15 15:40:32 argon pam_limits[4844]: wrong limit value
'cap_net_bind_service+eip'
The resolution for bug ID 74176 shows that capabilities support was added
to pam_limits.so in version 0.72-14, and the syntax I'm using in the
limits.conf file appears to be correct.
Looking at pam_limits.c, we see:
/* special case value when limiting logins */
if ((limit_item!=LIMIT_CHROOT)
(limit_value == 0 value_orig == *endptr)) { /*
no chars read */
if (strcmp(lim_value,-) != 0) {
_pam_log(LOG_DEBUG,wrong limit value '%s', lim_value);
return;
This is what is giving the error. If the item is not LIMIT_CHROOT, then
the value must be either a number or the string -.
For capabilities, the item is LIMIT_CAPS, and the value is a string like
cap_net_bind_service+eip, so we will always get this error when trying to
use capabilities.
The capabilities code in the source file appears to be fine, but this check
for numeric or - means that it is never reached.
I'm using Debian Linux 3.1 (sarge) with 2.6.12 Kernel on i386 platform.
argon# uname -a
Linux argon 2.6.12.2 #3 Tue Jul 12 13:06:10 BST 2005 i686 GNU/Linux
argon# dpkg -l | grep pam
ii libpam-modules 0.76-22Pluggable Authentication Modules for PAM
ii libpam-runtime 0.76-22Runtime support for the PAM library
ii libpam0g 0.76-22Pluggable Authentication Modules library
Roy Hills
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
