Re: "Version less than 0.0" in OVAL definitions

[Javier Fernandez-Sanguino]

On Mon, 17 May 2021 at 19:58, Serkan Özkan  wrote:

> Hello Seb,
> For some reason I didn't receive your email but saw it on the mailing list
> archive page.
> OVAL definitions are important for us and we would like to fix them if
> possible. Can you please let me know where the code is?
>
>
Hi Serkan,

I believe the latest version of the code for the OVAL definitions
generation is in the source code of the website, more specifically in this
directory:
https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/security/oval/generate.py.
An older version was the Perl script I developed (at
https://salsa.debian.org/webmaster-team/webwml/-/blob/master/english/security/parse-wml-oval.pl)
which is not functional anymore.

To generate the definitions, you need to have a copy of all the Debian
Security Advisories, which is available in the web source repository (at
https://salsa.debian.org/webmaster-team/webwml/-/tree/master/english/security
).

Hope the above helps.

Javier

>

Re: "Version less than 0.0" in OVAL definitions

[Javier Fernandez-Sanguino]

On Mon, 17 May 2021 at 09:58, Serkan Özkan  wrote:

> Hello,
> In theory, from version number numbering point of view only, yes less than
> 0.0 is valid. But in practice, as they are used in Debian OVAL definitions,
> I don't think they are. I think these state values might be incorrect,
> probably unintentionally. And there are many, thousands, of these less than
> 0.0 versions, I don't think they are actually intended to test for pre
> version 0 releases.
>

Dear Serkan,

There is a problem with the OVAL definitions published in the website. The
definitions are generated from the information available (in webwml files)
in the source code of the website but this is missing version information
in a way that can be properly interpreted by the scripts.

As a consequence, the output (the definitions) does not include an accurate
value for the version. To implement this properly we would need to
re-engineer the script that was created in 2010. Help here would be
appreciated, I can point you to the script + setup if you could help.

Hope above clarifies. Best regards,

Javier

Re: End-user laptop firewall available?

[Javier Fernandez-Sanguino]

On 9 December 2013 09:12, Hey, Lukas (KRZ)  wrote:
> C'mon guys,
>
> you spend way too much time discussing packet filtering rules and programs 
> for a
> machine which is hooked up via modem. Of course you can avoid things that 
> "might > happen" when dialed up or connected to some public wifi.

Just my 2c.

In this day and age a "USB dialup modem" might be a "3G connection
with a USB modem provided by a Telco company". That type of connection
gives you a public IP in an address space anyone can (and will) probe
and attack.

Publi WiFi is also risky, even if the address space is private, if the
WiFi is run by a densely populated area people (or trojans running in
other people's devices) might want to see what "machines are out
there" in the WiFi and probe/attack them. I've seen this quite a lot
in public hotspot areas.

Either way I think a firewall with a basic configuration is useful
anyway. Should you inadvertently install or enable something that
might be compromised from the outside you are making it more difficult
for them to do.

Also, since your device is not using anyother networked devices and
not sharing files/services/printers, the firewall configuration is
going to be simpler than, e.g., a laptop which is part of a LAN and
wants to access UPnP devices and use auto-discovery protocols (such as
avahi)

> You should rather worry if the announced gateway at the public library is the 
> real
> one ;)

True, ARP spoofing attacks are very common over public WiFi
connections (as a first step to MITM attacks). I've seen this
frequently in public WiFi at some congress I've attended to.

That's why you should exercise caution when using a WiFi network. I.e.
if you go to a SSL site and see a "invalid certificate" prompt from
your browser it's probably somebody trying to MITM you.

Regards

Javier


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAB9B7UvcdyoG+VTYGy5zDjtdcV3yicUx2=z9nytcaym3fyf...@mail.gmail.com

Re: What is this? "john" under cron.d??? Debian Squeeze

[Javier Fernandez-Sanguino]

On 12 November 2012 03:55, Jamie M  wrote:
> Just noticed an unfamiliar file in my Debian Squeeze: is called "john" found
> in cron.d.
>
> Does anyone know if this is a security risk, when all of a sudden I notice
> this file?
>
> Thank you and anything anyone can add is appreciated.
>

As you can see yourself if you search the package database (see [1])
the John password cracking program installs a 'john' task in
/etc/cron.d in order to test the system user's password strength every
so often.

There is nothing to worry about.

Next time you are worried about a file in your system, try using 'dpkg
-S ' to find which package has installed it there.

Regards

Javier

[1] 
http://packages.debian.org/search?searchon=contents&keywords=john&mode=exactfilename&suite=stable&arch=any


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAB9B7UsvFspxGFgZm8Ln3yHxP=Qvqjr48CEuQ=m6zyxgwvn...@mail.gmail.com

Re: Hardening Debian

[Javier Fernandez-Sanguino]

On 24 November 2010 00:52, CHACO  wrote:
>
>
> On Tue, Nov 23, 2010 at 5:48 PM, Daniel Hood  wrote:
>>
>> Does anyone have a good checklist or script to harden a vanilla debian
>> box after installation?
>
>
> http://www.debian.org/doc/manuals/securing-debian-howto/

More specifically, the checklist written in  the Appendix A - The
hardening process step by ste

http://www.debian.org/doc/manuals/securing-debian-howto/ap-harden-step.en.html

It is missing some additional steps related to security software that
can be installed in the system (HIDS), however. Also please note that
some content of the manual is not fully up to date.

Feel free to send any patches to the Debian Securing Manual content if
you find any sources which provide information (either improved
information or updated) that could be in the manual. As the manual
maintainer I really appreciate patches in the BTS.

Regards

Javier


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimdeg5k8r-9zd+i_ek1reybzto_mrcwdpwrd...@mail.gmail.com

Re: Nessus to be removed from Debian, please switch to OpenVAS - possibly in Non-Free repositories?

[Javier Fernandez-Sanguino]

2009/8/4 Joseph Abbotts :
> I'm all for having more tools to help settle my healthy paranoia but I'm not 
> seeing the server package:

Because, as I said in my email, this is only available in Unstable.
Openvas-server did not get released with Debian lenny (stable) and, in
any case, Nessus will not be removed from the current stable, just
from unstable.

> Also, if upstream is not going to maintain it at all and the Debian package 
> maintainer's time is then better spend helping with
> openVAS (if they so choose of course) then off it goes. It's just a heck of a 
> heavyweight to drop completely. Between it's reports and
> importing the NBE into metasploit for exploit confirmation, it's a hard habit 
> to give up. Any chance of seeing it in the Non-Free instead
>has upstream dropped it's upkeep completely? (Boo Nessus.. Wish they'd have 
>kept to the FOSS lower, value added retail upper
> model)

Well, OpenVAS does generate NBE reports too, you might want to try it
out in combination with Metasploit. In any case, Nessus' upstream
already provides Debian (and Ubuntu) packages for the latest releases.
These cannot go into Debian's non-free as they do not provide any
source code we can build from (even with a non-free license) and the
project doesn't have any authorisation to redistribute the binary
blobs.

Regards

Javier


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Openvas-distro-deb] Nessus to be removed from Debian, please switch to OpenVAS

[Javier Fernandez-Sanguino]

2009/8/3 Simon Ward :
> I wasn’t meaning to put pressure on a single person.  Sure, if there is
> enough demand, someone else, maybe me (although unlikely) could pick up
> package maintenance.  I was merely expressing my opinion that there is
> still a need for Nessus 2 for a little while longer.

Just to clarify: Nessus 2 (actually 2.2.10) will still be available in
Debian 5.0 (lenny). So user's in need of Nessus can use the current
stable release.

I have asked for its removal in the *unstable* release. If removed, it
would not be included in the next Debian stable release (which might
not come for more or less year) nor in Debian's 'testing' branch.

Regards

Javier


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Openvas-distro-deb] Nessus to be removed from Debian, please switch to OpenVAS

[Javier Fernandez-Sanguino]

2009/8/3 Stephen Frost :
> * Tim Brown (t...@nth-dimension.org.uk) wrote:
>> I don't see what there is to gain by asking Javier to split his efforts in
>> continuing to maintain Nessus when he has expressed a preference to allow
>> OpenVAS to take its place and has made significant contributions to make that
>> possible.
>
> While I appreciate Tim's comparison, I think the primary point here is
> this- If someone else wants to maintain Nessus 2 in Debian, I don't
> think anyone would object to spending that effort.  Javier's free to
> work on what he wants to.

Of course, if someone would like to keep working on Nessus in Debian
he can pick up the currnet packages (I just uploaded 2.2.11 and did
some minor bug fixes BTW). I just wouldn't recommend it.

Actually, I rather not have Nessus shipped with any other Debian
stable release as it is in the best interest of Debian and its users
to only provide software that is actively being maintained upstream.

Note, also, that from Tenable's point of view Debian's Nessus packages
are in that same "grey area" as OpenVAS is in where using them with
the non-free feeds could be against their license. Also, they made
sure that people would not be able to download new GPL plugins with
2.2.x (only registered plugins work) [1]. On these licensing issues,
please read the README.Dean files provided in the packages.

Regards

Javier


[1] For some more information see #443231: nessus-plugins: neither
nessus-update-plugins nor nessus-update-plugins-gpl work


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ping22: can not kill this process

[Javier Fernandez-Sanguino]

2008/1/4, Rick Moen <[EMAIL PROTECTED]>:
> Quoting Luis Mondesi ([EMAIL PROTECTED]):
>
> > It's time to tell PHP (via php.ini) not to allow any of those
> > functions that allow executing stuff from the system (system,
> > passthru, whatever).
>
> Amen to that.  Good starting point:
>  disable_functions = system, exec, passthru, popen, escapeshellcmd, shell_exec

Even better: /usr/share/doc/php5-common/examples/php.ini-paranoid
(it includes some more functions in that definition)

IIRC it includes those and some more. You might want to diff your
php.ini copy to that one to see the different things you could do to
improve your PHP installation.

Regards

Javier


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

Recent Securityfocus Colum and the Debian HOWTO

[Javier Fernandez-Sanguino Pena]

Jon, regarding your recent column at your insightful column at 
Securityfocus (http://www.securityfocus.com/columnists/48) regarding 
package manipulation and troyan insertion. Well, I have been discussing 
this issue in Debian for a while and just yesterday (IIRC, but could be 
checked at cvs.debian.org) sent a new version of the "Securing Debian 
HOWTO" (available at 
http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) 
which does talk about the package signing stuff and Debian's point of 
view regarding it. As you say in your column, you currently *can* check 
signatures in Debian, but, it's not enabled by default since the 
proposed scheme has not yet been decided upon (check the HOWTO for more 
information).


BTW, I did write this info *before* reading your column (just in case 
you were wondering), as a matter of fact I had the notes for about a 
week but had to get some time to write it down :)


In any case, I wanted to comment this info just in case you want to 
update your column to add additional info.


Regards

Javier Fernández-Sanguino Peña

Recent Securityfocus Colum and the Debian HOWTO

[Javier Fernandez-Sanguino Pena]

Jon, regarding your recent column at your insightful column at 
Securityfocus (http://www.securityfocus.com/columnists/48) regarding 
package manipulation and troyan insertion. Well, I have been discussing 
this issue in Debian for a while and just yesterday (IIRC, but could be 
checked at cvs.debian.org) sent a new version of the "Securing Debian 
HOWTO" (available at 
http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) 
which does talk about the package signing stuff and Debian's point of 
view regarding it. As you say in your column, you currently *can* check 
signatures in Debian, but, it's not enabled by default since the 
proposed scheme has not yet been decided upon (check the HOWTO for more 
information).

BTW, I did write this info *before* reading your column (just in case 
you were wondering), as a matter of fact I had the notes for about a 
week but had to get some time to write it down :)

In any case, I wanted to comment this info just in case you want to 
update your column to add additional info.

Regards

Javier Fernández-Sanguino Peña


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

Re: Security in a shell that starts ssh

[Javier Fernandez-Sanguino Peña]

Miquel Mart?n L?pez escribió:
> 
> Hi all!
> We have several vt-100 terminal that log to the naub server at our office.
> Still, some users without account in the main server would like to login to
> another machine, so I was planning on creating a passwordless acount with a
> shell that's a program that asks for usernames and then execs ssh -l
> username. I didn't want to do a script to avouid ppl hitting ctrl+c and
> having a passwordless account. I'm also worried about buffer-overflows and a
> miriad things I'm too newbie to understand, so I'd appreciate any comments
> on the security flaws you see on this:
> 
Umm.. programs can have security flaws. How about using port
redirection, a similar problem arised to a group of administrators I
belong to and someon proposed, using port redirection, the following:

iptables -t nat -A PREROUTING -p tcp --dport  -j DNAT --to
another_server:22

That way you do not depend on (sometimes unreliable) programs/daemons.
Of course, you needed, Linux 2.4. Another solution would be to use
applications such as (quick look to apt-cache search redirect) redir or
rinetd..

Javi

Re: Security in a shell that starts ssh

[Javier Fernandez-Sanguino Peña]

Miquel Mart?n L?pez escribió:
> 
> Hi all!
> We have several vt-100 terminal that log to the naub server at our office.
> Still, some users without account in the main server would like to login to
> another machine, so I was planning on creating a passwordless acount with a
> shell that's a program that asks for usernames and then execs ssh -l
> username. I didn't want to do a script to avouid ppl hitting ctrl+c and
> having a passwordless account. I'm also worried about buffer-overflows and a
> miriad things I'm too newbie to understand, so I'd appreciate any comments
> on the security flaws you see on this:
> 
Umm.. programs can have security flaws. How about using port
redirection, a similar problem arised to a group of administrators I
belong to and someon proposed, using port redirection, the following:

iptables -t nat -A PREROUTING -p tcp --dport  -j DNAT --to
another_server:22

That way you do not depend on (sometimes unreliable) programs/daemons.
Of course, you needed, Linux 2.4. Another solution would be to use
applications such as (quick look to apt-cache search redirect) redir or
rinetd..

Javi


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

Re: Checking behind the wall

[Javier Fernandez-Sanguino Peña]

> I was thinking of setting up a scanner (strobe/nmap/...?) to
> automatically do a scan from a cron and mail the results to me. However,
> is there any existing framework like this that I could leverage?
> 

Nessus can be tweaked to be able to report on a daily basis, its
reports (including nmap probes, as configured). You might want to take a
look at it (and maybe go through the mailing list archive since it was
discussed previously there)

Javi

Re: Checking behind the wall

[Javier Fernandez-Sanguino Peña]

> I was thinking of setting up a scanner (strobe/nmap/...?) to
> automatically do a scan from a cron and mail the results to me. However,
> is there any existing framework like this that I could leverage?
> 

Nessus can be tweaked to be able to report on a daily basis, its
reports (including nmap probes, as configured). You might want to take a
look at it (and maybe go through the mailing list archive since it was
discussed previously there)

Javi


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

Re: Logging practices (and why does it suck in Debian?)

[Javier Fernandez-Sanguino Peña]

JonesMB escribió:
> 
> >> Neato. That's 3 people in total who think it's a good idea..
> >It's probably the 3 people in total who bother to check the
logs...
> 
> make that 4.  I always have an xterm with a tail -f /var/log/syslog running

no. better, 5.
Also, I would like this documented for inclusion in the
Secure-Debian-HOWTO
located at http://www.debian.org/doc/ddp (I have not received many
contributions
BTW)

JAvi

Re: Logging practices (and why does it suck in Debian?)

[Javier Fernandez-Sanguino Peña]

JonesMB escribió:
> 
> >> Neato. That's 3 people in total who think it's a good idea..
> >It's probably the 3 people in total who bother to check the
logs...
> 
> make that 4.  I always have an xterm with a tail -f /var/log/syslog running

no. better, 5.
Also, I would like this documented for inclusion in the
Secure-Debian-HOWTO
located at http://www.debian.org/doc/ddp (I have not received many
contributions
BTW)

JAvi


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

Re: Radius server?

[Javier Fernandez-Sanguino Peña]

This is not really the place... take a look at freeradius.org for a 
good (and
free) software. You can check there also the Radius freeradius is based on
(Cistron). Please subscribe to the mailing lists for more information on it
(besides the documentation available on the website)

Javi

> Patrice Langlois escribió:
> 
> Hello,
> 
> I'm looking for a radius server. Do you know a good solution or any good
> documentation about it?
> 
> Thanks for your help.
> 
> PL

Re: Radius server?

[Javier Fernandez-Sanguino Peña]

This is not really the place... take a look at freeradius.org for a good (and
free) software. You can check there also the Radius freeradius is based on
(Cistron). Please subscribe to the mailing lists for more information on it
(besides the documentation available on the website)

Javi

> Patrice Langlois escribió:
> 
> Hello,
> 
> I'm looking for a radius server. Do you know a good solution or any good
> documentation about it?
> 
> Thanks for your help.
> 
> PL


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

Re: Nessusd

[Javier Fernandez-Sanguino Peña]

[EMAIL PROTECTED] escribió:
> 
> Greetings!
> 
> On 13 Feb, Craig wrote:
> > I am trying to setup nessusd ... been though the config files but I keep
> > getting the following error message
> > when trying to connect via the windows client:
> >
> > ERROR: Server doesn't support NSP/0.3 protocol. Connection terminated.
> 
> The nessusd in Debian 2.2 is a 0.9x version whereas the Windows client
> is a 1.0.7 (probably) release. The client-server protocol changed some
> time ago. So you either have to use 0.9x server AND client - or both
> 1.0.x.  Best solution would be to update the server to 1.0.7.  Just
> unins tall the debian file, grab the current tarballs from
> http://www.nessus.org/ and install that manually.
> 
> Bye
> Volker

Nessus 1.0.6 is available in unstable, I currently have successfully
compiled it in potato (not an easy matter BTW), if anyone is interested in
the packages, feel free to ask

Javi

Re: Nessusd

[Javier Fernandez-Sanguino Peña]

[EMAIL PROTECTED] escribió:
> 
> Greetings!
> 
> On 13 Feb, Craig wrote:
> > I am trying to setup nessusd ... been though the config files but I keep
> > getting the following error message
> > when trying to connect via the windows client:
> >
> > ERROR: Server doesn't support NSP/0.3 protocol. Connection terminated.
> 
> The nessusd in Debian 2.2 is a 0.9x version whereas the Windows client
> is a 1.0.7 (probably) release. The client-server protocol changed some
> time ago. So you either have to use 0.9x server AND client - or both
> 1.0.x.  Best solution would be to update the server to 1.0.7.  Just
> unins tall the debian file, grab the current tarballs from
> http://www.nessus.org/ and install that manually.
> 
> Bye
> Volker

Nessus 1.0.6 is available in unstable, I currently have successfully
compiled it in potato (not an easy matter BTW), if anyone is interested in
the packages, feel free to ask

Javi


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

Re: Updating the Securing HOWTO

[Javier Fernandez-Sanguino Peña]

Alexander Reelsen escribió:
> 
> Hi
> 
> On Sun, Feb 04, 2001 at 12:56:11PM +0100, Javier Fdz-Sanguino Pen~a wrote:
> Heh. Incidentally I updated my own HOWTO yesterday as well. Here are the
> changes:
> - Added a security update after installation paragraph
> - Added a proftpd paragraph
> - This time really wrote something about XDM, sorry for last time
> 
> You mind to share the stuff on your TODO? Perhaps I could do something as
> well. I will have some free time next week.

All the comments are in the source... check the source Luke :)

http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

You will see that you can get colored diffs from previous version so 
it's
easier to see what has changed/moved from previous version.

Regards

Javi

Re: Updating the Securing HOWTO

[Javier Fernandez-Sanguino Peña]

Yes sorry, I wrote too fast.
BTW Url for the source is :

http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

and for the online version:

http://www.debian.org/doc/manuals/securing-debian-howto/index.html

Javi

Jordan Bettis escribió:
> 
> On Sun, Feb 04, 2001 at 12:56:11PM +0100, Javier Fdz-Sanguino Pen~a wrote:
> > http://www.debian.org/ddp). I have added some comments regarding information
> 
> I think you got this URL wrong, do you mean ?
> 
> --
> Jordan Bettis 
> Showing up is 80% of life.
> -- Woody Allen
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Updating the Securing HOWTO

[Javier Fernandez-Sanguino Peña]

Alexander Reelsen escribió:
> 
> Hi
> 
> On Sun, Feb 04, 2001 at 12:56:11PM +0100, Javier Fdz-Sanguino Pen~a wrote:
> Heh. Incidentally I updated my own HOWTO yesterday as well. Here are the
> changes:
> - Added a security update after installation paragraph
> - Added a proftpd paragraph
> - This time really wrote something about XDM, sorry for last time
> 
> You mind to share the stuff on your TODO? Perhaps I could do something as
> well. I will have some free time next week.

All the comments are in the source... check the source Luke :)

http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

You will see that you can get colored diffs from previous version so it's
easier to see what has changed/moved from previous version.

Regards

Javi


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

Re: Updating the Securing HOWTO

[Javier Fernandez-Sanguino Peña]

Yes sorry, I wrote too fast.
BTW Url for the source is :
http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

and for the online version:

http://www.debian.org/doc/manuals/securing-debian-howto/index.html

Javi

Jordan Bettis escribió:
> 
> On Sun, Feb 04, 2001 at 12:56:11PM +0100, Javier Fdz-Sanguino Pen~a wrote:
> > http://www.debian.org/ddp). I have added some comments regarding information
> 
> I think you got this URL wrong, do you mean ?
> 
> --
> Jordan Bettis 
> Showing up is 80% of life.
> -- Woody Allen
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


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

Re: Disappointment in security handling in Debian

[Javier Fernandez-Sanguino Peña]

Daniel Jacobowitz escribió:
> 
> On Thu, Feb 01, 2001 at 02:12:40PM +0100, Mathieu Dessus wrote:
> > This is not directly related to this thread, but this post reminds me
> > that generally the translations pages of Security Information page (
> > http://www.debian.org/security/ ) are generally not up to date.
> > And with the automatic switch to the page corresponding to your
> > languange's preference, I've been fooled several times, thinking that
> > Debian security was not up to date.
> >
> > What about adding a link to the original version with an warning or
> > simply disabling automatic swicthing language for this page ?
> 
> The web people tell me that this was a bug in the automatic
> regeneration of the web pages; it should be fixed.
> 
> Dan

Currently there is an application in place on the web system that 
allows it to
tell users when the translation is not up to date. So if you feel that there are
problems with translations, please, file a bug report.

Javi

Re: Disappointment in security handling in Debian

[Javier Fernandez-Sanguino Peña]

Daniel Jacobowitz escribió:
> 
> On Thu, Feb 01, 2001 at 02:12:40PM +0100, Mathieu Dessus wrote:
> > This is not directly related to this thread, but this post reminds me
> > that generally the translations pages of Security Information page (
> > http://www.debian.org/security/ ) are generally not up to date.
> > And with the automatic switch to the page corresponding to your
> > languange's preference, I've been fooled several times, thinking that
> > Debian security was not up to date.
> >
> > What about adding a link to the original version with an warning or
> > simply disabling automatic swicthing language for this page ?
> 
> The web people tell me that this was a bug in the automatic
> regeneration of the web pages; it should be fixed.
> 
> Dan

Currently there is an application in place on the web system that allows it to
tell users when the translation is not up to date. So if you feel that there are
problems with translations, please, file a bug report.

Javi


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

Security-Enhanced Linux in Debian?

[Javier Fernandez-Sanguino Peña]

I have gone through http://www.nsa.gov/selinux/ (Security-Enhanced 
Linux) and
it seems to be some interesting work on how Linux security can be overall
improved, I've found with distress, however that the patches applied seem to be
from RedHat versions (not original source).
Before starting to do my own work with it, however, I would like to 
know if
other Debian people have heard of the project and what do they think of it.
Could be used for Debian? 
They seem to be working on auditing the source of what we could 
consider our
"base-filesystem" so the kind of code-auditing that was proposed in the list
earlier could start here.

Regards

Javi

Signatures of packages and security-patches

[Javier Fernandez-Sanguino Peña]

I've read the Debian GNU/Linux section quickly from this paper
http://razor.bindview.com/publish/papers/os-patch.html which was announced at
the bugtrack mailing list, and have found it quite interesting (will have to
print it in order to read it thoroughly).
Hopefully, this might let us know how our current model compares 
against other
distribution/commercial vendors and see how (if) it can be improved. I just
wanted to bring it on to the list in case other people are not aware of it.

Regards

Javi

Security-Enhanced Linux in Debian?

[Javier Fernandez-Sanguino Peña]

I have gone through http://www.nsa.gov/selinux/ (Security-Enhanced Linux) and
it seems to be some interesting work on how Linux security can be overall
improved, I've found with distress, however that the patches applied seem to be
from RedHat versions (not original source).
Before starting to do my own work with it, however, I would like to know if
other Debian people have heard of the project and what do they think of it.
Could be used for Debian? 
They seem to be working on auditing the source of what we could consider our
"base-filesystem" so the kind of code-auditing that was proposed in the list
earlier could start here.

Regards

Javi


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

Signatures of packages and security-patches

[Javier Fernandez-Sanguino Peña]

I've read the Debian GNU/Linux section quickly from this paper
http://razor.bindview.com/publish/papers/os-patch.html which was announced at
the bugtrack mailing list, and have found it quite interesting (will have to
print it in order to read it thoroughly).
Hopefully, this might let us know how our current model compares against other
distribution/commercial vendors and see how (if) it can be improved. I just
wanted to bring it on to the list in case other people are not aware of it.

Regards

Javi


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

Checklist (was Re: OS Hardening)

[Javier Fernandez-Sanguino Peña]

My checklist is:

1.- custom install (do not select tasks) w/ shadow passwords
2.- go through deselect and remove packages before doing a install, leave
bare-minimum
3.- (the things in the debian-hardening-howto: quotas, login definitions, lilo)
4.- check init.d scripts, remove unwanted with package (check with dpkg -S do
dpkg --purge), if they are useful but not interesting to enable on startup use
update-rc.d XXX remove
5.- Install services that will be used in bastioned host
6.- check services enabled: ps aux, netstat -n --inet, lsof -i
7.- Remove RPC (if not using NFS or any other RPC service, i.e. always)
8.- check inetd services: grep -v "^#" | sort |uniq. remove unwanted with
update-inetd
9.- check if inetd services are wrapped (tcpd) configure hosts.deny hosts.allow
10.- check which services are running as root (with ps aux, netstat).
Consider change to a given user/group (start-stop-daemon -- -u XXX -g XXX)
Consider chrooting.
11.- (if services changed to another user) Check files from services (dpkg -L)
and change ownership.
12.- Recheck services enabled.
13.- Test install: services work as expected
14.- Check setting with network scanner, analysis of vulnerabilities
15.- Install problem detectors (snort, logging...)
16.- Recheck with network scanner. Do detectors warn you?
(for the truly paranoid ;) 

17.- Add firewall capabilities. Offer only selected services. 
18.- Recheck install (13)
19.- Recheck with network scanner.

And no, I'm not in a mental institution ;)

Javi

Securing Debian now in the DDP

[Javier Fernandez-Sanguino Peña]

As promised, I have included the Securing-Debian HOWTO in DDP's CVS and 
updated
the DDP web pages (check Administrator's Manuals in www.debian.org/doc/ddp)
As it says now the development version will be available from:

http://www.debian.org/doc/manuals/securing-debian-howto/index.html

and the SGML sources from the CVS at:

http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

Best regards

Javi

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

I've thought on the Debian metapackage... how about this:

task-security
Depends: documentation (securing-howto, lasg)
Suggests:  task-security-audit, task-firewall-tools, task-security-tools
Recomends: task-network-tools


task-security-audit
Depends: nessusd, snort, logcheck, ippl, tcpdump, sxid, syslog-ng, arpwatch
(tripwire, satan, and saint are all non-free IIRC)

task-security-tools
Depends: pwgen, makepasswd, john, otp, osh, rbash, ssh ,gnupg, tcpd

task-network-tools
ecomends: cheops, scotty, queso, nmap, ethereal, netdiag, karpski

task-firewall-tools
Depends: gfc,firestarter, easyfw (last two not currently in Debian, but will be
soon)

Any thoughts?

Javi

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

Jeremy Gaddis escribió:
> 
(..)
> 
> Do a stock installation and see if a new user wouldn't need a "hardening
> script".  At a guess, telnet, ftp, portmapper, nfsd, and the like are probably
> running.  I can see where a "hardening script" could come into play here,
> asking the user if he needs service "x" running, with a default answer of no.
> Unless the user specifically states that he wants it running, it won't be.

Yes! So what we really need is a script that will test your security 
and make
suggestions to the user/sysadmin. Even if sometimes it pesters around too much,
for example:

Script: you are using telnetd do you really need insecure connections like this?
User: yes, absolutely
Script: telnetd-ssl is a better replacement, why don't you install it?
User: no, mi clients do not support it
Script: and why not tcp-wrap it so you can just give it to given locations
User: no
Script: are you sure? I can help you with the hosts.allow/deny stuff 
User: oh wel...


Could make for a good AI  ;)

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

"S.Salman Ahmed" escribió:
> 
> [No need to CC: me guys, I read each and every list mail I
> receive. Thanks.]
> 
> > "BMA" == Bradley M Alexander <[EMAIL PROTECTED]> writes:
> BMA>  The problem with this is that, generally speaking, there are
> BMA> as many configurations as there are sysadmins or users out
> BMA> there. You would run the risk of bogging down in the mire of
> BMA> details and asking questions that the user really has no clue
> BMA> about. In this case, as a security person, the idea of
> BMA> "profiles" in lieu of actual knowledge or familiarity is a
> BMA> dangerous thing.
> [snip]
> BMA>
> BMA> Personally I turn them off and rely on secure shell on my
> BMA> network at home.
> BMA>
> 
> I use SSH on my home network as well.
> 
> You make some good points in your email Bradley. I think that if I were
> to every to install a Linux distro using some kind of install profiles,
> I would still want to know why things were installed a certain way.
> 
> After reading Andres' email about how Mandrake handles and implements
> security profiles, and your email, I am convinced that they aren't the
> best solution to securing a system. Afterall, any Linux installation is
> only as secure as the user/administrator who performed the install and
> tends to the post-install and administration tasks.
> 
> After doing a Debian install, I have my own checklist of things I do to
> *try* and secure the installation.
> 

*Please* post it. It could be really useful for documents like the
Securing-Debian-HOWTO, I have my own checklist and will update the HOWTO with it
soon. 

So, for all of you.. new thread? : checklist of things to do for a 
secure
setup?

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

> Oh, I totally agree; this would have to be on a per-package basis,
> however.  Hence, it would rely on each maintainers willingness
> to do so.  For example, a chrooted bind (running as user nobody
> or something) would be nice, but the bind maintainer has refused
> (at least until bind 9.1 is released.. see bug #50013).  A debconf
> option would be ideal here; the trick is to convince the maintainer
> to add it.
> 

Not only chrooted. Bind could be easily made to run as 'named' user and 
group,
and it is easy to script this if the maintainer does not provide it. Alas,
Debian policy does not allow a package to change another one upon installation,
but that does not mean we cannot provide a harden script that makes this.
Users should *not* have to read through a document thoroughly to have a 
secure
installation. If things are not provided as hardened as necessary since only a
limited range of users will need this hardened, there should be automatic
procedures to turn off to a hardened setting. I.e. do not make users:

1.- addgroup named
2.- adduser --system --ingroup named named
3.- edit /etc/init.d/bind in order to make start-stop give -u named -g named
options to named.

IMHO.

Regards

Javi
Javi

Checklist (was Re: OS Hardening)

[Javier Fernandez-Sanguino Peña]

My checklist is:

1.- custom install (do not select tasks) w/ shadow passwords
2.- go through deselect and remove packages before doing a install, leave
bare-minimum
3.- (the things in the debian-hardening-howto: quotas, login definitions, lilo)
4.- check init.d scripts, remove unwanted with package (check with dpkg -S do
dpkg --purge), if they are useful but not interesting to enable on startup use
update-rc.d XXX remove
5.- Install services that will be used in bastioned host
6.- check services enabled: ps aux, netstat -n --inet, lsof -i
7.- Remove RPC (if not using NFS or any other RPC service, i.e. always)
8.- check inetd services: grep -v "^#" | sort |uniq. remove unwanted with
update-inetd
9.- check if inetd services are wrapped (tcpd) configure hosts.deny hosts.allow
10.- check which services are running as root (with ps aux, netstat).
Consider change to a given user/group (start-stop-daemon -- -u XXX -g XXX)
Consider chrooting.
11.- (if services changed to another user) Check files from services (dpkg -L)
and change ownership.
12.- Recheck services enabled.
13.- Test install: services work as expected
14.- Check setting with network scanner, analysis of vulnerabilities
15.- Install problem detectors (snort, logging...)
16.- Recheck with network scanner. Do detectors warn you?
(for the truly paranoid ;) 

17.- Add firewall capabilities. Offer only selected services. 
18.- Recheck install (13)
19.- Recheck with network scanner.

And no, I'm not in a mental institution ;)

Javi


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

Securing Debian now in the DDP

[Javier Fernandez-Sanguino Peña]

As promised, I have included the Securing-Debian HOWTO in DDP's CVS and updated
the DDP web pages (check Administrator's Manuals in www.debian.org/doc/ddp)
As it says now the development version will be available from:

http://www.debian.org/doc/manuals/securing-debian-howto/index.html

and the SGML sources from the CVS at:

http://cvs.debian.org/ddp/manuals.sgml/securing-howto/?cvsroot=debian-doc

Best regards

Javi


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

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

I've thought on the Debian metapackage... how about this:

task-security
Depends: documentation (securing-howto, lasg)
Suggests:  task-security-audit, task-firewall-tools, task-security-tools
Recomends: task-network-tools


task-security-audit
Depends: nessusd, snort, logcheck, ippl, tcpdump, sxid, syslog-ng, arpwatch
(tripwire, satan, and saint are all non-free IIRC)

task-security-tools
Depends: pwgen, makepasswd, john, otp, osh, rbash, ssh ,gnupg, tcpd

task-network-tools
ecomends: cheops, scotty, queso, nmap, ethereal, netdiag, karpski

task-firewall-tools
Depends: gfc,firestarter, easyfw (last two not currently in Debian, but will be
soon)

Any thoughts?

Javi


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

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

Jeremy Gaddis escribió:
> 
(..)
> 
> Do a stock installation and see if a new user wouldn't need a "hardening
> script".  At a guess, telnet, ftp, portmapper, nfsd, and the like are probably
> running.  I can see where a "hardening script" could come into play here,
> asking the user if he needs service "x" running, with a default answer of no.
> Unless the user specifically states that he wants it running, it won't be.

Yes! So what we really need is a script that will test your security and make
suggestions to the user/sysadmin. Even if sometimes it pesters around too much,
for example:

Script: you are using telnetd do you really need insecure connections like this?
User: yes, absolutely
Script: telnetd-ssl is a better replacement, why don't you install it?
User: no, mi clients do not support it
Script: and why not tcp-wrap it so you can just give it to given locations
User: no
Script: are you sure? I can help you with the hosts.allow/deny stuff 
User: oh wel...


Could make for a good AI  ;)

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

"S.Salman Ahmed" escribió:
> 
> [No need to CC: me guys, I read each and every list mail I
> receive. Thanks.]
> 
> > "BMA" == Bradley M Alexander <[EMAIL PROTECTED]> writes:
> BMA>  The problem with this is that, generally speaking, there are
> BMA> as many configurations as there are sysadmins or users out
> BMA> there. You would run the risk of bogging down in the mire of
> BMA> details and asking questions that the user really has no clue
> BMA> about. In this case, as a security person, the idea of
> BMA> "profiles" in lieu of actual knowledge or familiarity is a
> BMA> dangerous thing.
> [snip]
> BMA>
> BMA> Personally I turn them off and rely on secure shell on my
> BMA> network at home.
> BMA>
> 
> I use SSH on my home network as well.
> 
> You make some good points in your email Bradley. I think that if I were
> to every to install a Linux distro using some kind of install profiles,
> I would still want to know why things were installed a certain way.
> 
> After reading Andres' email about how Mandrake handles and implements
> security profiles, and your email, I am convinced that they aren't the
> best solution to securing a system. Afterall, any Linux installation is
> only as secure as the user/administrator who performed the install and
> tends to the post-install and administration tasks.
> 
> After doing a Debian install, I have my own checklist of things I do to
> *try* and secure the installation.
> 

*Please* post it. It could be really useful for documents like the
Securing-Debian-HOWTO, I have my own checklist and will update the HOWTO with it
soon. 

So, for all of you.. new thread? : checklist of things to do for a secure
setup?

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: OS Hardening

[Javier Fernandez-Sanguino Peña]

> Oh, I totally agree; this would have to be on a per-package basis,
> however.  Hence, it would rely on each maintainers willingness
> to do so.  For example, a chrooted bind (running as user nobody
> or something) would be nice, but the bind maintainer has refused
> (at least until bind 9.1 is released.. see bug #50013).  A debconf
> option would be ideal here; the trick is to convince the maintainer
> to add it.
> 

Not only chrooted. Bind could be easily made to run as 'named' user and group,
and it is easy to script this if the maintainer does not provide it. Alas,
Debian policy does not allow a package to change another one upon installation,
but that does not mean we cannot provide a harden script that makes this.
Users should *not* have to read through a document thoroughly to have a secure
installation. If things are not provided as hardened as necessary since only a
limited range of users will need this hardened, there should be automatic
procedures to turn off to a hardened setting. I.e. do not make users:

1.- addgroup named
2.- adduser --system --ingroup named named
3.- edit /etc/init.d/bind in order to make start-stop give -u named -g named
options to named.

IMHO.

Regards

Javi
Javi


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

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> On 00-12-04 Javier Fernandez-Sanguino Peña wrote:

I'm sorry. Having read this I have gone through the list archives and I 
have
not found any reference to this discussion.
Yes, there was a discussion regarding metapackages but on how to use it 
to make
automatic downloads. I'm talking of other issues here
(documentation+dependancies+hardening scripts). If this has been talked about
before feel free to point me to the exact thread

> > (I'm taking this out of the previous thread)
> 
> >   I've been giving some thought on a Debian metapackage related to
> >   security.. and I think that it might be useful to have a package
> >   that :
> 
> Do we really need to discuss this again? There has just been one
> discussion about this and you can read about it in the archives.
> 
> Ciao
>  Christian
> 
> P.S.: Turn that v-card off.

Done.

Javi

Re: Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> [Please do not send me Ccs, I read the list where I'm posting to. If not
> I explicitly state this at the beginnning of my mail.]

Ok.
> 
> On 00-12-04 Javier Fernandez-Sanguino Peña wrote:
> > Christian Kurz escribió:
> > >
> > >
> > > >   I have checked it out and would really like to see it included in
> > > >   the DDP and think that debian security guru's should help in
> > >
> > > Well, which package should include this documentation? May I also say,
> > > that some debian security interested guys helped in creating this
> > > document?
> 
> >   As for the first one I do not know, maybe we should create a
> >   debian-security package to provide this kind of information like the
> >   java-common package provides the Java FAQ and the Java policy as
> 
> Well, I think including this documentation into doc-debian would then be
> more sinful, because creating a new package for one document isn't a
> good idea.

As a matter of fact, all documents in the DDP are made as separate 
packages,
doc-debian, for example, includes only the FAQ, the package-maintainer the
document of the same name, maint-guide the "New Maintainer Guide", java-common
the "Debian JAVA FAQ". So I would say that the standard procedure is to have
this documents in different packages..

> 
> >   well as being a suited metapackage.  How about having a package
> >   providing this document and some useful scripts (for example
> >   cron.daily updates from security.debian.org) and dependancies on
> >   security-related packages. Kind of a meta-package...
> 
> No, we had one discussion about this some time ago and came to the
> conclusion that such a metapackage isn't a good idea.

Umm.. I have looked in the archive and I have only seen references to a
meta-package to do automatica updates from the security.debian.org site. Did you
talk on documentation and dependancies too?

> 
> > > >   ideas? Also, since the package would depend on other packages we
> > > >   need to have this in the chrooted environment too, is there an
> > > >   *easy* way to do this?  (without needing to have two package
> > > >   databases)
> > >
> > > No, that's why I think chroots should always be set up by the admin and
> > > not by any tool. And a good idea knows how to create chroots even for
> > > programs using dynamic linking.
> > >
> >   I'm not quite the same thinking here. You could use the powerful 
> > package
> > management tools in order to automatically do this like:
> 
> >   (user) - ok I want bind installed but chrooted in /home/bind
> >   (apt/dpkg) - downloading bind
> >   (apt/dpkg) - installing in /home/bind
> 
> No, if you would have read the discussion on debian-devel you would also
> know, that this won't be possible.

Because the discussion in debian-devel (which I missed but I have read a
resumed text on debian-planet) was centered on other issues. Was the chroot case
pushed into the discussion there.
I am sorry, I do *not* read debian-devel, I barely have time to keep up 
with
the weekly news and debian planet summaries.

> 
> >   (apt/dpkg) - checking dependancies of bind
> >   (apt/dpkg) - moving related libraries (to allow dynamic linking) into
> >   /home/bind
> >   (apt/dpkg) - changing default init.d script to run bind but chrooted 
> > into
> >   /home/bind
> 
> Can always be done via an external script, that the administrator
> starts, if he really wants to chroot the daemon.
> >
> >   ()
> 
> >   (user) - dpkg --status bind
> >   (dpkg) Package: bind...
> >   Chrooted-in: /home/bind
> 
> Won't work and I think this is somehting that Wichert won't include in
> dpkg. Also you should be free to choose the place to chroot for
> yourself.

I do know that it will not work since it is not implemented in dpkg. 
The main
issue here is: "Is it useful? (security-wise)"


> 
> >   Did it make any sense?
> 
> Some and please turn that v-card of.
> 

Sorry If I do, I sometimes forget to remove it when I send mails... 
will have
to look on how to do it on a per-address basis.

Javi

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> On 00-12-04 Javier Fernandez-Sanguino Peña wrote:

I'm sorry. Having read this I have gone through the list archives and I have
not found any reference to this discussion.
Yes, there was a discussion regarding metapackages but on how to use it to make
automatic downloads. I'm talking of other issues here
(documentation+dependancies+hardening scripts). If this has been talked about
before feel free to point me to the exact thread

> > (I'm taking this out of the previous thread)
> 
> >   I've been giving some thought on a Debian metapackage related to
> >   security.. and I think that it might be useful to have a package
> >   that :
> 
> Do we really need to discuss this again? There has just been one
> discussion about this and you can read about it in the archives.
> 
> Ciao
>  Christian
> 
> P.S.: Turn that v-card off.

Done.

Javi


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

Re: Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> [Please do not send me Ccs, I read the list where I'm posting to. If not
> I explicitly state this at the beginnning of my mail.]

Ok.
> 
> On 00-12-04 Javier Fernandez-Sanguino Peña wrote:
> > Christian Kurz escribió:
> > >
> > >
> > > >   I have checked it out and would really like to see it included in
> > > >   the DDP and think that debian security guru's should help in
> > >
> > > Well, which package should include this documentation? May I also say,
> > > that some debian security interested guys helped in creating this
> > > document?
> 
> >   As for the first one I do not know, maybe we should create a
> >   debian-security package to provide this kind of information like the
> >   java-common package provides the Java FAQ and the Java policy as
> 
> Well, I think including this documentation into doc-debian would then be
> more sinful, because creating a new package for one document isn't a
> good idea.

As a matter of fact, all documents in the DDP are made as separate packages,
doc-debian, for example, includes only the FAQ, the package-maintainer the
document of the same name, maint-guide the "New Maintainer Guide", java-common
the "Debian JAVA FAQ". So I would say that the standard procedure is to have
this documents in different packages..

> 
> >   well as being a suited metapackage.  How about having a package
> >   providing this document and some useful scripts (for example
> >   cron.daily updates from security.debian.org) and dependancies on
> >   security-related packages. Kind of a meta-package...
> 
> No, we had one discussion about this some time ago and came to the
> conclusion that such a metapackage isn't a good idea.

Umm.. I have looked in the archive and I have only seen references to a
meta-package to do automatica updates from the security.debian.org site. Did you
talk on documentation and dependancies too?

> 
> > > >   ideas? Also, since the package would depend on other packages we
> > > >   need to have this in the chrooted environment too, is there an
> > > >   *easy* way to do this?  (without needing to have two package
> > > >   databases)
> > >
> > > No, that's why I think chroots should always be set up by the admin and
> > > not by any tool. And a good idea knows how to create chroots even for
> > > programs using dynamic linking.
> > >
> >   I'm not quite the same thinking here. You could use the powerful package
> > management tools in order to automatically do this like:
> 
> >   (user) - ok I want bind installed but chrooted in /home/bind
> >   (apt/dpkg) - downloading bind
> >   (apt/dpkg) - installing in /home/bind
> 
> No, if you would have read the discussion on debian-devel you would also
> know, that this won't be possible.

Because the discussion in debian-devel (which I missed but I have read a
resumed text on debian-planet) was centered on other issues. Was the chroot case
pushed into the discussion there.
I am sorry, I do *not* read debian-devel, I barely have time to keep up with
the weekly news and debian planet summaries.

> 
> >   (apt/dpkg) - checking dependancies of bind
> >   (apt/dpkg) - moving related libraries (to allow dynamic linking) into
> >   /home/bind
> >   (apt/dpkg) - changing default init.d script to run bind but chrooted into
> >   /home/bind
> 
> Can always be done via an external script, that the administrator
> starts, if he really wants to chroot the daemon.
> >
> >   ()
> 
> >   (user) - dpkg --status bind
> >   (dpkg) Package: bind...
> >   Chrooted-in: /home/bind
> 
> Won't work and I think this is somehting that Wichert won't include in
> dpkg. Also you should be free to choose the place to chroot for
> yourself.

I do know that it will not work since it is not implemented in dpkg. The main
issue here is: "Is it useful? (security-wise)"


> 
> >   Did it make any sense?
> 
> Some and please turn that v-card of.
> 

Sorry If I do, I sometimes forget to remove it when I send mails... will have
to look on how to do it on a per-address basis.

Javi


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

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

Wel... nessus is almost graphic also (although it does run on the CLI) 
so you
would just install the server (nessusd), and firestarter (see 
http://sourceforge.net/projects/firestarter/) would also be out of the list.
We could maybe split it into security and network-analysis maybe (since 
most of
them are of that kind...)

Javi

> 
> * Javier Fernandez-Sanguino Peña
> 
> | For example, I would add dependancies on snort, nessus, nmap, queso,
> | cracklib2, ethereal, firestarter (when available as a Debian
> | package), john, netdiag, sniffit, otp, makepasswd, logcheck,
> | secpolicy, libpam, lasg...
> 
> etheral?  That's an X program - I would _never_ install X on a
> server. :)
>begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Securing Debian HOWTO - Now in SGML

[Javier Fernandez-Sanguino Peña]

Ok. I will like to include this, with your permission in the Debian's 
DDP. An
put you as the main maintainer. Is this ok?

Alexander Reelsen escribió:
> 
> Hi folks
> 
> As I've had sometime during the weekend I rewrote the HOWTO in SGML as
> some of you had wished. The URL is (note the slash ;))
> 
> http://joker.rhwd.de/doc/Securing-Debian-HOWTO/
> 
> Currently there is the text, html and SGML version available. Ought to be
> enough for everybody. I cleaned up some paragraphs (I wonder what awful
(...)
> 
> Oh, and if someone volunteers to write a paragraph about
> dpkg-statoverrides, I would not be the only one to be grateful I guess ;)
> I don't have a working woody station at the moment so I am not able to
> write something about it.

I might have time to do what I did when I opened my little mouth in the 
debian-java mailing list. I asked "is there a FAQ" answer: "no, write one", and
I went through all the archived mail in the last half year in order to have a
useful Debian-Java FAQ (now available at your nearest DDP :)

One of the things I think will be most useful in order to give content 
to the
FAQ is to re-read all the discussions that have taken place in the
debian-security mailing list, since many of them will assault gurus/novice
users...

Regards

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

(I'm taking this out of the previous thread)

I've been giving some thought on a Debian metapackage related to 
security.. and
I think that it might be useful to have a package that :

- included security-related documentation (aka Debian Security FAQ)
- provide useful scripts in examples dir(for example cron.daily updates from
security.debian.org)
- provided dependencies for free security tools in Debian so that users do not
have to be gurus in order to know *what* to install.

For example, I would add dependancies on snort, nessus, nmap, queso, 
cracklib2,
ethereal, firestarter (when available as a Debian package), john, netdiag,
sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have left
others outs). Kind of a swiss-army security knife :)

It could also Conflict with known no-security packages..

Any ideas? Is it really interesting or just a pointless idea?

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> 
> >   I have checked it out and would really like to see it included in
> >   the DDP and think that debian security guru's should help in
> 
> Well, which package should include this documentation? May I also say,
> that some debian security interested guys helped in creating this
> document?

As for the first one I do not know, maybe we should create a 
debian-security
package to provide this kind of information like the java-common package
provides the Java FAQ and the Java policy as well as being a suited metapackage.
How about having a package providing this document and some useful 
scripts (for
example cron.daily updates from security.debian.org) and dependancies on
security-related packages. Kind of a meta-package...

> 
> >   improving it. One thing I would like to have nicely documented is to
> >   make chroot jails. But not Linux-wide but Debian-specific, that is:
> 
> What should be documented? Mostly you need to have all config files,
> libaries and binaries in the same structure as under / in a seperate
> dir, where you chroot to.

See below.

> 
> >   is there a way to build packages available in Debian in order to
> >   easily install them chrooted?  My first thought is that only if the
> 
> You don't need to statically link packages to chroot them. You can also
> chroot them, if they use dynamic linking, but then you need to copy
> these libs also into the chroot-dir.

I do know.

> 
> >   ideas? Also, since the package would depend on other packages we
> >   need to have this in the chrooted environment too, is there an
> >   *easy* way to do this?  (without needing to have two package
> >   databases)
> 
> No, that's why I think chroots should always be set up by the admin and
> not by any tool. And a good idea knows how to create chroots even for
> programs using dynamic linking.
> 
I'm not quite the same thinking here. You could use the powerful 
package 
management tools in order to automatically do this like:

(user) - ok I want bind installed but chrooted in /home/bind
(apt/dpkg) - downloading bind
(apt/dpkg) - installing in /home/bind
(apt/dpkg) - checking dependancies of bind
(apt/dpkg) - moving related libraries (to allow dynamic linking) into
/home/bind
(apt/dpkg) - changing default init.d script to run bind but chrooted 
into
/home/bind

()

(user) - dpkg --status bind
(dpkg) Package: bind...
Chrooted-in: /home/bind


Did it make any sense?

Regards

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

Wel... nessus is almost graphic also (although it does run on the CLI) so you
would just install the server (nessusd), and firestarter (see 
http://sourceforge.net/projects/firestarter/) would also be out of the list.
We could maybe split it into security and network-analysis maybe (since most of
them are of that kind...)

Javi

> 
> * Javier Fernandez-Sanguino Peña
> 
> | For example, I would add dependancies on snort, nessus, nmap, queso,
> | cracklib2, ethereal, firestarter (when available as a Debian
> | package), john, netdiag, sniffit, otp, makepasswd, logcheck,
> | secpolicy, libpam, lasg...
> 
> etheral?  That's an X program - I would _never_ install X on a
> server. :)
>

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Securing Debian HOWTO - Now in SGML

[Javier Fernandez-Sanguino Peña]

Ok. I will like to include this, with your permission in the Debian's DDP. An
put you as the main maintainer. Is this ok?

Alexander Reelsen escribió:
> 
> Hi folks
> 
> As I've had sometime during the weekend I rewrote the HOWTO in SGML as
> some of you had wished. The URL is (note the slash ;))
> 
> http://joker.rhwd.de/doc/Securing-Debian-HOWTO/
> 
> Currently there is the text, html and SGML version available. Ought to be
> enough for everybody. I cleaned up some paragraphs (I wonder what awful
(...)
> 
> Oh, and if someone volunteers to write a paragraph about
> dpkg-statoverrides, I would not be the only one to be grateful I guess ;)
> I don't have a working woody station at the moment so I am not able to
> write something about it.

I might have time to do what I did when I opened my little mouth in the 
debian-java mailing list. I asked "is there a FAQ" answer: "no, write one", and
I went through all the archived mail in the last half year in order to have a
useful Debian-Java FAQ (now available at your nearest DDP :)

One of the things I think will be most useful in order to give content to the
FAQ is to re-read all the discussions that have taken place in the
debian-security mailing list, since many of them will assault gurus/novice
users...

Regards

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

What should a Debian-security metapackage should provide?

[Javier Fernandez-Sanguino Peña]

(I'm taking this out of the previous thread)

I've been giving some thought on a Debian metapackage related to security.. and
I think that it might be useful to have a package that :

- included security-related documentation (aka Debian Security FAQ)
- provide useful scripts in examples dir(for example cron.daily updates from
security.debian.org)
- provided dependencies for free security tools in Debian so that users do not
have to be gurus in order to know *what* to install.

For example, I would add dependancies on snort, nessus, nmap, queso, cracklib2,
ethereal, firestarter (when available as a Debian package), john, netdiag,
sniffit, otp, makepasswd, logcheck, secpolicy, libpam, lasg... (might have left
others outs). Kind of a swiss-army security knife :)

It could also Conflict with known no-security packages..

Any ideas? Is it really interesting or just a pointless idea?

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

Christian Kurz escribió:
> 
> 
> >   I have checked it out and would really like to see it included in
> >   the DDP and think that debian security guru's should help in
> 
> Well, which package should include this documentation? May I also say,
> that some debian security interested guys helped in creating this
> document?

As for the first one I do not know, maybe we should create a debian-security
package to provide this kind of information like the java-common package
provides the Java FAQ and the Java policy as well as being a suited metapackage.
How about having a package providing this document and some useful scripts (for
example cron.daily updates from security.debian.org) and dependancies on
security-related packages. Kind of a meta-package...

> 
> >   improving it. One thing I would like to have nicely documented is to
> >   make chroot jails. But not Linux-wide but Debian-specific, that is:
> 
> What should be documented? Mostly you need to have all config files,
> libaries and binaries in the same structure as under / in a seperate
> dir, where you chroot to.

See below.

> 
> >   is there a way to build packages available in Debian in order to
> >   easily install them chrooted?  My first thought is that only if the
> 
> You don't need to statically link packages to chroot them. You can also
> chroot them, if they use dynamic linking, but then you need to copy
> these libs also into the chroot-dir.

I do know.

> 
> >   ideas? Also, since the package would depend on other packages we
> >   need to have this in the chrooted environment too, is there an
> >   *easy* way to do this?  (without needing to have two package
> >   databases)
> 
> No, that's why I think chroots should always be set up by the admin and
> not by any tool. And a good idea knows how to create chroots even for
> programs using dynamic linking.
> 
I'm not quite the same thinking here. You could use the powerful package 
management tools in order to automatically do this like:

(user) - ok I want bind installed but chrooted in /home/bind
(apt/dpkg) - downloading bind
(apt/dpkg) - installing in /home/bind
(apt/dpkg) - checking dependancies of bind
(apt/dpkg) - moving related libraries (to allow dynamic linking) into
/home/bind
(apt/dpkg) - changing default init.d script to run bind but chrooted into
/home/bind

()

(user) - dpkg --status bind
(dpkg) Package: bind...
Chrooted-in: /home/bind


Did it make any sense?

Regards

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

I do not know if other developers are aware, but there is a nice 
Security HOWTO
available in  http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by
Alexander Reelsen (which I am sending this to in case he is not on the list). 
I have checked it out and would really like to see it included in the 
DDP and
think that debian security guru's should help in improving it. One thing I would
like to have nicely documented is to make chroot jails. But not Linux-wide but
Debian-specific, that is: is there a way to build packages available in Debian
in order to easily install them chrooted?
My first thought is that only if the original source uses autoconf 
(which would
allow setting the $prefix/$exec_prefix, etc.. in order to install it correctly).
Any ideas? Also, since the package would depend on other packages we need to
have this in the chrooted environment too, is there an *easy* way to do this?
(without needing to have two package databases)

Best regards

Javi

Debian Security-HOWTO

[Javier Fernandez-Sanguino Peña]

I do not know if other developers are aware, but there is a nice Security HOWTO
available in  http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by
Alexander Reelsen (which I am sending this to in case he is not on the list). 
I have checked it out and would really like to see it included in the DDP and
think that debian security guru's should help in improving it. One thing I would
like to have nicely documented is to make chroot jails. But not Linux-wide but
Debian-specific, that is: is there a way to build packages available in Debian
in order to easily install them chrooted?
My first thought is that only if the original source uses autoconf (which would
allow setting the $prefix/$exec_prefix, etc.. in order to install it correctly).
Any ideas? Also, since the package would depend on other packages we need to
have this in the chrooted environment too, is there an *easy* way to do this?
(without needing to have two package databases)

Best regards

Javi


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

Re: su vulnerability

[Javier Fernandez-Sanguino Peña]

One thing I wonder is why does not Debian issue advisories to popular 
mailing
lists (linux-security on securityportal and bugtrack on securityfocus comes to
mind). Also, I do not see this posted at security.debian.org
I am currently maintaining my status as Debian maintainer but starting 
to move
my focus towards security (I finished my life as student and working now on a
security related company). 
So, I'm willing to help the security team in posting these 
announcements (both
on web and on security lists). It seems that some hands might be needed :)
I  have another proyect in mind, but will send it later on...

Regards

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: su vulnerability

[Javier Fernandez-Sanguino Peña]

One thing I wonder is why does not Debian issue advisories to popular mailing
lists (linux-security on securityportal and bugtrack on securityfocus comes to
mind). Also, I do not see this posted at security.debian.org
I am currently maintaining my status as Debian maintainer but starting to move
my focus towards security (I finished my life as student and working now on a
security related company). 
So, I'm willing to help the security team in posting these announcements (both
on web and on security lists). It seems that some hands might be needed :)
I  have another proyect in mind, but will send it later on...

Regards

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Groff/troff security exposure

[Javier Fernandez-Sanguino Peña]

Ummm yes, as I answered Alan you need to be logged on as root. This
compromise is dangerous because a not-very-paranoic root user might do commands
like 'man' while in a public dir (like /tmp, or a users's), and a user might be
able to put a troyan there.
As a matter of fact, man does run as seteuid man. But there are other 
packages
using groff (for example, a2ps or gnosamba) that might not work as man. I have
not checked their sources, though.

Regards

Javi

"Noah L. Meyerhans" escribió:
> 
> -BEGIN PGP SIGNED MESSAGE-
> 
> On Thu, 5 Oct 2000, Alan KF LAU wrote:
> 
> > Just a question. I've tried it on my own server which is Debian 2.2.17 
> > woody(unstable) version. I got the following message when trying 2:
> >
> > ./troffrc:1: can't open `/etc/passwd' for appending: Permission denied
> > ./troffrc:2: no stream named 'passwds'
> > ./troffrc:3: no stream named 'passwds'
> > 
> >
> > Is this bug already fixed in Debian 2.2 Woody(unstable)?
> 
> Javier's email does specify that you need to be logged in as root.  I
> assume you were not.
> 
> There have been similar attacks to this in other packages for quite some
> time.  I believe it would be reasonable for man to run setuid man, would
> it not?  In fact, considering that there's a man user in /etc/passwd by
> default in Debian, why isn't it?
> 
> noah
>begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Re: Groff/troff security exposure

[Javier Fernandez-Sanguino Peña]

Ummm yes, as I answered Alan you need to be logged on as root. This
compromise is dangerous because a not-very-paranoic root user might do commands
like 'man' while in a public dir (like /tmp, or a users's), and a user might be
able to put a troyan there.
As a matter of fact, man does run as seteuid man. But there are other packages
using groff (for example, a2ps or gnosamba) that might not work as man. I have
not checked their sources, though.

Regards

Javi

"Noah L. Meyerhans" escribió:
> 
> -BEGIN PGP SIGNED MESSAGE-
> 
> On Thu, 5 Oct 2000, Alan KF LAU wrote:
> 
> > Just a question. I've tried it on my own server which is Debian 2.2.17 
>woody(unstable) version. I got the following message when trying 2:
> >
> > ./troffrc:1: can't open `/etc/passwd' for appending: Permission denied
> > ./troffrc:2: no stream named 'passwds'
> > ./troffrc:3: no stream named 'passwds'
> > 
> >
> > Is this bug already fixed in Debian 2.2 Woody(unstable)?
> 
> Javier's email does specify that you need to be logged in as root.  I
> assume you were not.
> 
> There have been similar attacks to this in other packages for quite some
> time.  I believe it would be reasonable for man to run setuid man, would
> it not?  In fact, considering that there's a man user in /etc/passwd by
> default in Debian, why isn't it?
> 
> noah
>

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Groff/troff security exposure

[Javier Fernandez-Sanguino Peña]

I have just read a security announcement sent by ISSalert regarding 
groff
manipulation that can lead to a security compromise (available at 
http://xforce.iss.net/alerts/advise63.php). 
The problem is that both troff and groff read files in the working 
directory
which can spin off commands in behalf of the user. This can be very sensible if
the one running a 'man' command is root since the whole system is exposed.
For in depth information refer to the link above, I have tested an 
exploit in
Debian GNU/Linux 2.2 and works as expected.

1.- groff attack
Reason: Groff will read any "devXX" directory available at the local dir and
process 'postpro' commands execv'ing them. 
Test: Put a 'devlatin1' copy of /usr/share/groff/font/devlatin1/ files in the
/tmp dir, edit the DESC file to include (at the end):
postpro ../../../tmp/exploit

Now put your favourite exploit in /tmp/exploit (for example add a new 
user to
/etc/passwd and /etc/shadow)

Then run 'groff -Tlatin1 ls.1' in /tmp as root. See what happens

2.- troff attack
Reason: troff will read any 'troffrc' file in the current dir
Test: put a troffrc file in the /tmp dir, check the troff manpage to see what it
can do. For example:
.opena passwds /etc/passwd
.write passwds guest:x:1:1::/:/bin/sh
.close passwds
.opena passwds /etc/shadow
.write passwds guest:AqualifiedHashPsswd:11215:0:9:7:::
.close passwds

And run 'troff *anyfile*'
Check /etc/passwd :)

Now, this will not exactly work when doing 'man' since it will 
1.- set its directory to where $MANPATH  or where /etc/manpath.config points to
2.- change euid to 'man'.

However, man is not the only system that uses groff. I've checked 
package
dependencies and, for example: gnosamba (configuration utility for Samba that
will surely run as root since it has to change /etc/samba) and a2ps *do* use
groff.
I have not checked their sources on how could this be exploited, but if 
they
have not be carefully coded to check this situation (like man is).

My suggestion: groff and troff should *not* extend their paths to 
current
directory, *or* should not allow processing files from different users if owner
is root (to avoid a root compromise).

Regards

Javier Fernández-Sanguino Peña
Debian GNU/Linux developerbegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Groff/troff security exposure

[Javier Fernandez-Sanguino Peña]

I have just read a security announcement sent by ISSalert regarding groff
manipulation that can lead to a security compromise (available at 
http://xforce.iss.net/alerts/advise63.php). 
The problem is that both troff and groff read files in the working directory
which can spin off commands in behalf of the user. This can be very sensible if
the one running a 'man' command is root since the whole system is exposed.
For in depth information refer to the link above, I have tested an exploit in
Debian GNU/Linux 2.2 and works as expected.

1.- groff attack
Reason: Groff will read any "devXX" directory available at the local dir and
process 'postpro' commands execv'ing them. 
Test: Put a 'devlatin1' copy of /usr/share/groff/font/devlatin1/ files in the
/tmp dir, edit the DESC file to include (at the end):
postpro ../../../tmp/exploit

Now put your favourite exploit in /tmp/exploit (for example add a new user to
/etc/passwd and /etc/shadow)

Then run 'groff -Tlatin1 ls.1' in /tmp as root. See what happens

2.- troff attack
Reason: troff will read any 'troffrc' file in the current dir
Test: put a troffrc file in the /tmp dir, check the troff manpage to see what it
can do. For example:
.opena passwds /etc/passwd
.write passwds guest:x:1:1::/:/bin/sh
.close passwds
.opena passwds /etc/shadow
.write passwds guest:AqualifiedHashPsswd:11215:0:9:7:::
.close passwds

And run 'troff *anyfile*'
Check /etc/passwd :)

Now, this will not exactly work when doing 'man' since it will 
1.- set its directory to where $MANPATH  or where /etc/manpath.config points to
2.- change euid to 'man'.

However, man is not the only system that uses groff. I've checked package
dependencies and, for example: gnosamba (configuration utility for Samba that
will surely run as root since it has to change /etc/samba) and a2ps *do* use
groff.
I have not checked their sources on how could this be exploited, but if they
have not be carefully coded to check this situation (like man is).

My suggestion: groff and troff should *not* extend their paths to current
directory, *or* should not allow processing files from different users if owner
is root (to avoid a root compromise).

Regards

Javier Fernández-Sanguino Peña
Debian GNU/Linux developer

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

GV vulnerable to buffer exploit

[Javier Fernandez-Sanguino Peña]

I have just tested this on a Debian 2.2 box and works (save for gv not 
being
setuid). It seems that gv is vulnerable to a buffer overrun exploit which might
make it dump out to a shell. 
More information available at
http://216.204.66.95/archive/exploits/09_00/%5bCODE.13.09.00%5d.linux-gv.c
Version tested: 3.5.8

This might be already known but I have not seen it in the lists 
previously, if
it is known please disregard this.


Regards

Javibegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

GV vulnerable to buffer exploit

[Javier Fernandez-Sanguino Peña]

I have just tested this on a Debian 2.2 box and works (save for gv not being
setuid). It seems that gv is vulnerable to a buffer overrun exploit which might
make it dump out to a shell. 
More information available at
http://216.204.66.95/archive/exploits/09_00/%5bCODE.13.09.00%5d.linux-gv.c
Version tested: 3.5.8

This might be already known but I have not seen it in the lists previously, if
it is known please disregard this.


Regards

Javi

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-91 806 46 40
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;28448
fn:Javier Fernández-Sanguino Peña
end:vcard

Buffer exploit on gopherd

[Javier Fernandez-Sanguino Peña]

I have just read this on xforce.iss.net 
(http://xforce.iss.net/static/5102.php). It seems that there is
a buffer overflow condition on the halidate function that a remote
attacker could exploit.
I am unable (yet) to check the sources and see if Debian
is vulnerable, but Debian's version is 2.3.1-2, which makes it
possible.

Regards

Javier Fernández-Sanguino Peña
Debian GNU/Linux developerbegin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-918064432
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;32352
fn:Javier Fernández-Sanguino Peña
end:vcard

Buffer exploit on gopherd

[Javier Fernandez-Sanguino Peña]

I have just read this on xforce.iss.net 
(http://xforce.iss.net/static/5102.php). It seems that there is
a buffer overflow condition on the halidate function that a remote
attacker could exploit.
I am unable (yet) to check the sources and see if Debian
is vulnerable, but Debian's version is 2.3.1-2, which makes it
possible.

Regards

Javier Fernández-Sanguino Peña
Debian GNU/Linux developer

begin:vcard 
n:Fernández-Sanguino Peña;Javier
tel;fax:+34-91 806 46 41
tel;work:+34-918064432
x-mozilla-html:FALSE
org:SGI-GMV sistemas;Seguridad Lógica
adr:;;Sector Foresta 1;Tres Cantos;Madrid;E-28760;Spain
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;32352
fn:Javier Fernández-Sanguino Peña
end:vcard