CVE-2023-41105 not fixed in bookworm

[Richard van den Berg]

Dear security team,

May I ask why CVE-2023-41105 was marked as " (Minor issue)"[1] ?

As the CVE description says there are plausible cases where this can 
lead to security issues.


There is a backport available for python 3.11 and it seems most other 
distros have patched this CVE.


Kind regards,

Richard van den Berg

1: https://security-tracker.debian.org/tracker/CVE-2023-41105

Re: incorrect version number on security-tracker.debian.org

[Richard Lewis]

On Wed, 2 Nov 2022 at 20:41, Adam D. Barratt  wrote:
> On Wed, 2022-11-02 at 18:36 +, RL wrote:
> > I think the data on security-tracker.debian.org may be incomplete.
> >
> >
> > For example the following links suggest that grub had a vulnerability
> >that was fixed in: 2.06-3~deb11u1 but bullseye has 2.06-3~deb11u2
> >(ending in u2 not u1)
> >
>
> bullseye *doesn't* have deb11u2 yet. It's in proposed-updates and
> stable-updates, but stable still has deb11u1 until the next point
> release.

aha, thank-you.

is there a possibility that
https://security-tracker.debian.org/tracker/CVE-2021-3695 could learn
to list 'bullseye-updates' with deb11u2 listed as 'fixed'?

and that this info could propogate into debsecan

(i see it also affects
https://security-tracker.debian.org/tracker/CVE-2021-33574 where
2.31-13+deb11u5 is installed but the tracker, and therefore (I assume)
debsecan only knows that u4 is fixed - or am i just doing something
stupid by installing anything from proposed-updates ?)

Re: What is the best free HIDS for Debian

[Richard van den Berg]

On 10/05/2022 05:37, Vitaly Krasheninnikov wrote:


Thank you for debcheckroot. I think it is a great project, which makes us one 
step closer to a verifiable Debian system.
In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed 
us: "..._.GM" and "..._..M".
According to the description on your website, it means the modification of the 
file permissions, not the actual content.


Thanks a lot for clarifying this. I found the interpretation of the 
results of debcheckroot at https://www.elstel.org/debcheckroot/


On 06/05/2022 15:52, Elmar Stellnberger wrote:

Am 06.05.22 um 15:05 schrieb Sylvain Sécherre:
> Here's the fileserror.lis:
> ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755
> ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 
755

> ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755
> ...

  I hope you won´t mind that I am citing the output of debcheckroot 
you have given me.
  These three files point to an infection with a rootkit. Don´t care 
about modified configuration files like in /etc too much (but you may 
still have a look at them). Executable files on the other hand must 
never be modified. If these three files are different it means that 
someone has altered your system. If you look at the man pages of these 
executables then you also know that a maker of a rootkit would have 
interest to modify exactly these files. 


Since you are the author of the debcheckroot tool, why do you think that 
the G (group) and M (mode) flags indicate the content of the files were 
altered? Or did you make a mistake and forgot what the output of 
debcheckroot actually means? If so, does this change your opinion that a 
rootkit is installed on this system?


Kind regards,

Richard

Re: /home/loser is with permissions 755, default umask 0022

[Richard van den Berg]

On 13-11-2020 08:18, Georgi Guninski wrote:

Some more exploit vectors from the FD list:
https://seclists.org/fulldisclosure/2020/Nov/13

Partial results:

1. mutt (text email client) exposes ~/.mutt/muttrc,
which might contain the imap password in plaintext.


Interesting find. Please report this to the mutt package maintainer 
using reportbug[1].




2. Some time ago on a multiuser debian mirror we found a lot of data,
including the wordpress password of the admin.


As Giacomo already explained, there is nothing an OS can do to stop the 
insecure behavior of its users.




3. Anything created by EDITOR NEWFILE is readable, unless the directory
prevents. This include root doing EDITOR /etc/NEWFILE


Yes, that is indeed the default. If you don't like it, you can change 
the system umask in /etc/login.defs or /etc/profile


Somehow I get the feeling you are using debian-security@lists.debian.org 
to report a security issues with Debian. This is however just a 
discussion mailing list about Debian security. If you wish to report a 
serious security issue (which I did not find in your E-mails) you need 
to contact the Debian Security Team[2].


Kind regards,

Richard

[1]: https://wiki.debian.org/reportbug
[2]: https://www.debian.org/security/faq#contact

Side issue/question -- {Re: how to deal with widely used packages ...}

[Richard Owlett]

I've causally/intermittently followed this thread.
There appears to be a problem of definitions and applicability.

Is there a page of definitions for jessie, jessie-updates, stretch, 
stretch-updates, stretch-backports, stretch-backports-sloppy, buster, 
buster-updates, buster-backports, bullseye, sid, experimental, 
"fastpace/not ready", "Fast Track repo", etc.


I use only "stable" so doesn't seem to affect me.

Re: Two HDD on Desktop PC

[Richard Owlett]

On 08/04/2019 02:55 PM, *MORON* GM1 wrote:

RTFM.


Could not be bothered giving useful reply

Re: [SECURITY] [DSA 4187-1] linux security update

[Richard Lucassen]

On Fri, 4 May 2018 10:06:58 +0800
Paul Wise <p...@debian.org> wrote:

> > One of the consequences is that openntpd (or a program like
> > rdate) hangs until the crng is initialized.
> 
> What do these two programs require entropy for?

That's the question. The only thing I saw that these two programs
normally send 123/UDP packets to query the configured timeservers, but
apparently these packets are blocked until crng is initialized.
At least "rdate" uses "getrandom", that's what you see rdate is waiting
for when you "strace -p "

-- 
___
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------+
| Richard Lucassen, Utrecht|
+--+

Re: [SECURITY] [DSA 4187-1] linux security update

[richard lucassen]

On Thu, 03 May 2018 01:44:06 +0100
Ben Hutchings <b...@debian.org> wrote:

> > There are multiple reports on #ganeti that this update breaks
> > networking in certain circumstances, probably multiple tun/tap
> > device configurations. No more details or a proper bug report yet
> > as I haven't experienced this myself, but mentioning in case it
> > saves anyone else breakage.[...]
> 
> I believe I understand this. Creating a tun/tap device using a name
> pattern such as "tun%d" (or empty name) will now fail if the number
> substituted is not 0.  There is an upstream fix for this that I failed
> to spot in time.

There is also an big increase in time before random is initialized:

[  182.811840] random: crng init done

This is a machine on bare metal. On other environments like proxmox I've
seen:

[  303.993638] random: crng init done

Downgrading to the previous kernel resolves the problem (normally a few
seconds). One of the consequences is that openntpd (or a program like
rdate) hangs until the crng is initialized.

R.
-- 
richard lucassen
http://contact.xaq.nl/

Re: ModSecurity Debian 8

[Richard Waterbeek]

Mod-security,

[opinioned]

"Blocks certain words that are normal. Decision to depend on it, depends
on what your Apache server, serves. I run a forum that sometimes has
over ten spambots at once. Running without that piece of art"

However, few, but not so few, 'no likey-likey' Mod security, and I
regret remembering their bias.

Sorry, I can't tell much more then that. Responses to this post I deem
'friendly' [my post that is, not so friendly responses, I have a thick
skin], might trigger my mind. [or won't]

[/opinoned]

-- 
Richard W. 
The Netherlands

Krzysztof Kokot schreef op ma 20-03-2017 om 23:03 [+0100]:
> Hi, 
> 
> 
> I can't help you a lot, in fact the only thing I can do is recommend
> you this
> article: 
> https://www.digitalocean.com/community/tutorials/how-to-set-up-mod_security-with-apache-on-debian-ubuntu.
>  It works for me.
> 
> 
> Cheers,
> Krzysztof Kokot
> 
> 
> 20 mar 2017 19:53 "lann...@runbox.com" <lann...@runbox.com>
> napisał(a):
> 
> Hi,
> I have spent about 2 days trying to understand how to setup
> mod-security on my web server.
> 
>  I choose to rely on packages in the official repo, so if
> possible I will not compile packages.
> 
> Is correct to say that I can't have mod-security in nginx?
> Is mod-security only available in apache2?
> 
> Then I'm looking for some instruction about installing. There
> are a lot of outdated material and is difficult to learn the
> right stuff.
> 
> 
> Here is what I have typed:
> 
> 
> apt-get install libcurl3-gnutls liblua5.1-0 libxml2
> apt-get install libapache2-mod-security2
> apt-get install modsecuriy-crs
> sudo
> mv /etc/modsecurity/modsecurity.conf-recommended 
> /etc/modsecurity/modsecurity.conf
> sudo nano /etc/modsecurity/modsecurity.conf
> 
> 
> I have turned on the option SecRuleEngine
> 
> git clone
> https://github.com/SpiderLabs/owasp-modsecurity-crs.git
> 
> 
> Now... my questions are:
> 
> 1) Where I have to put the rules
> 2) Which other config files I have to edit
> 3) How I enable modsecurity on my website
> 4) Do you have sample config file to share?
> 
> 
> Thanks a lot for your help.
> 
> Anders. LA.
> 
> 
> 
> 

Re: vulnerability in 8.6

[Richard Waterbeek]

Hi,

I wrote that I searched for a '686' image but that was meant for this
VirtualBox I have, my 64Bit processor only can emulate 32Bit.

uname -ar gave; Linux  3.16.0-4-amd64 #1 SMP Debian 3.16.36-1
+deb8u1 (2016-09-03) x86_64 GNU/Linux

dpkg -l | grep linux-image gave; linux-image-3.16.0-4-amd64
3.16.36-1+deb8u1

I ran; sudo apt-get update, followed by sudo apt-get upgrade and that
gave;

The following packages will be upgraded:
  tzdata tzdata-java
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 268 kB of archives.
After this operation, 16.4 kB of additional disk space will be used.

This seems a little unexpected to me. A real long time ago I update just
the kernel once on a Slackware machine and finished that with;
update-grub.

I thought a sudo apt-get install linux-image-3.16.0-4-amd64 followed by
update-grub is sufficient to upgrade the kernel. 

So I did; sudo apt-get install, preceded by sudo apt-get upgrade and
that gave;

linux-image-3.16.0-4-amd64 is already the newest version.

And just now it is clear to me that something must be wrong, so thank
you for helping enabling me to clarify my questions.

Hoping to hear from you what to do now.

-- 
Richard Waterbeek <richard...@versatel.nl>



Vladislav Kurz schreef op do 10-11-2016 om 10:28 [+0100]:
> On 11/10/16 04:20, Richard Waterbeek wrote:
> > Hi Salvatore, Ozgur,
> > 
> > You posted this url; https://www.debian.org/security/2016/dsa-3696
> > 
> > But, I have looked for a update and I went to Debian package search and
> > searched for; 'kernel image 686
> > pae' 
> > [https://packages.debian.org/search?suite=stable=all=any=names=kernel+image+686+pae]
> > 
> > This gave one result, which is; 'kernel-image-3.16.0-4-686-pae-di' and
> > written with that, 'Linux kernel binary image for the Debian installer
> > 3.16.36-1+deb8u1: i386'
> 
> Check what kernel is your system running:
> 
> # uname -a
> Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2
> (2016-10-19) x86_64 GNU/Linux
> 
> The kernel packages for running system (not installer) are:
> linux-image-*** not kernel-image-***
> 
> You can chek what is installed by: dpkg -l|grep linux
> 
> > And I read that I need a '+deb8u2' kernel?
> > 
> > Can someone explain to me what to do next? I have the assumption that a
> > 'apt-get install "name-of-required-kerne-package"' would be sufficient?
> 
> apt-get update; apt-get upgrade
> 
> followed by reboot should be sufficient.
> 

Re: vulnerability in 8.6

[Richard Waterbeek]

Hi Salvatore, Ozgur,

You posted this url; https://www.debian.org/security/2016/dsa-3696

I've been looking in to this exploit, and did what Ozgur found on
Github, and I learned that my system is vulnerable. I had a difference,
which is that dirtyc0w, did overwrite the read-only 'foo' file, but it
hang, and it also did write up to the length of the original content of
that file. So my 'foo' was six bytes long and I attempted to overwrite
with a longer sequence, and it stopped. After seeing this had happened,
I started over with a new 'foo' file, and this time I attempted a
shorter byte sequence and it also hang. From what I've read, it doesn't
seem to hang. 

I'm guessing that overwriting the sudoers file for example would make
the exploiter a rooted user on the exploited system..

But, I have looked for a update and I went to Debian package search and
searched for; 'kernel image 686
pae' 
[https://packages.debian.org/search?suite=stable=all=any=names=kernel+image+686+pae]

This gave one result, which is; 'kernel-image-3.16.0-4-686-pae-di' and
written with that, 'Linux kernel binary image for the Debian installer
3.16.36-1+deb8u1: i386'

And I read that I need a '+deb8u2' kernel?

Can someone explain to me what to do next? I have the assumption that a
'apt-get install "name-of-required-kerne-package"' would be sufficient?

If not, can someone point me in the right direction on what to do,
because the link Salvatore posted, it says on that page; 

'For the stable distribution (jessie), these problems have been fixed in
version 3.16.36-1+deb8u2.

We recommend that you upgrade your linux packages.'

-- 
Richard Waterbeek <richard...@versatel.nl>



Salvatore Bonaccorso schreef op ma 07-11-2016 om 17:09 [+0100]:
> Hi,
> 
> On Mon, Nov 07, 2016 at 06:54:55PM +0300, Ozgur wrote:
> > Hi all,
> > 
> > I have been reading security articles and I seen a test with Debian Linux
> > vulnerability of kernel. I tested and given a successful exploit.
> > 
> > List a vuln:
> > 
> > https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
> > 
> > My testing:
> > 
> > dirtycow.c (status: success)
> > cowroot.c (status: success)
> > 
> > For example, I have installed Debian and kernel version are as follow:
> > 
> > Linux 3.16.0-4-amd64 (Debian 8.6)
> > 
> > I created a "zoo" file with root privileges and locked a file:
> > 
> > # echo I'm a root > foo
> > # chmod 0404 foo
> > # ls -la foo
> > -r-r-- 1 root root 11 Nov  7 10:13 foo
> > 
> > then I'm return my user (not root) and I downloaded the exploit script and
> > run it:
> > 
> > $ gcc -pthread dirtyc0w.c -o dirtyc0w
> > $ ./dirtyc0w foo blabla
> > $ cat foo
> > blabla
> > 
> > what is the suggestion on this exploit?
> 
> Have you installed the Kernel update as per the security advisory
> DSA-3696-1? Which kernel image do you have installed, which kernel is
> running?
> 
>  [0] https://www.debian.org/security/2016/dsa-3696
> 
> Regards,
> Salvatore
> 

Re: vulnerability in 8.6

[Richard van den Berg]

On 7 Nov 2016, at 16:54, Ozgur <okara...@member.fsf.org> wrote:
> 
> Linux 3.16.0-4-amd64 (Debian 8.6)
> 

Always test security vulnerabilities on a fully patched system. According to 
https://security-tracker.debian.org/tracker/CVE-2016-5195 this was fixed in 
version 3.16.36-1+deb2 of the linux package. 

 Kind regards,

Richard

Re: Security features in the upcoming release (Stretch)

[Richard Owlett]

On 9/23/2016 9:44 PM, Darko Gavrilovic wrote:

I think there is an Apparmor progress page, no?

https://wiki.debian.org/AppArmor/Progress


Quoting above page:
"AppArmor/Progress (last edited 2015-08-14 09:33:50 ..."  :<





Just wondering, if you like Fedora/RH SELinux & AppArmor
implementation better, then why not just stick to deploying them?


I read the OP being in the position of wanting to use Debian but 
choice was being made more dificult by lack of information. YMMV




On Fri, Sep 23, 2016 at 9:49 PM, stefano frabetti
 wrote:

He, and those like me, deserve a polite/germane/relevant response.


Bravo!  +1

Re: Security features in the upcoming release (Stretch)

[Richard Owlett]

On 9/23/2016 12:42 PM, Reed Black wrote:

On Fri, Sep 23, 2016 at 6:42 AM, Jonathan Hutchins
> wrote:

It is difficult for me to rationalize a serious concern for
"security"
with the idea that one should lie back and expect the
packaging team to
take care of it all for you.  If you are concerned with
security, you
should be actively configuring security features yourself,
not expecting
that someone else has the same priorities that you do.


Advance notice of what's landing helps an engineer know what to
focus on, and where work would be duplicated. Resources are
finite. That includes time. Not everything needs to be done in
house in order to be "serious."



I'll take it one step further.
Mr. Hutchins never responded to questions raised by Mr. Largo.
Mr. Hutchins may have multiple PhD's in "Internet Security" with 
decades of experience.

*I DO NOT*
I am actually an "END USER". I've been told I am an 
"administrator" *SOLELY* because I'm the ultimate authority of 
the multiple systems residing on my table top .


Mr. Largo has evidently done his "homework".
He, and those like me, deserve a polite/germane/relevant response.

DSA for CVE-2016-5696 (off-path blind TCP session attack)

[Richard van den Berg]

Dear Debian security team,

Will there be a DSA written for CVE-2016-5696 [1]? It looks pretty 
serious and I'd like to fix this on my systems ASAP.


Kind regards,

Richard van den Berg

[1] https://security-tracker.debian.org/tracker/CVE-2016-5696

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

[Richard Owlett]

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


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

Request additional test data. Was: [sqlite] Crippling query plan change between 3.7.13 and 3.8.10.2

[Richard Hipp]

 using the new SQLite version.

 I will figure out a way to rewrite the query so that it runs
 reasonably fast again (which will address our immediate needs), but
 maybe there is something that can be fixed in the planner as well.
 ___
 sqlite-users mailing list
 sqlite-us...@mailinglists.sqlite.org
 http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



-- 
D. Richard Hipp
d...@sqlite.org


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALwJ=Mx+Z-qdnANdBYQoD3urYAie=ibzecmjff9njgsi9hb...@mail.gmail.com

Re: [sqlite] Crippling query plan change between 3.7.13 and 3.8.10.2

[Richard Hipp]

 27   00
 132 Null   0 63000
 133 Integer1 64000
 134 OpenRead   9 180 7  00
 135 OpenRead   20190 k(1,nil)   02
 136 Column 0 0 65   00
 137 SeekGE 20143   651  00
 138 IdxGT  20143   651  00
 139 IdxRowid   2066000
 140 Seek   9 66000
 141 Column 9 6 63   00
 142 DecrJumpZero   64143   000
 143 Close  9 0 000
 144 Close  200 000
 145 Copy   6328000
 146 Null   0 67000
 147 Integer1 68000
 148 OpenRead   10220 5  00
 149 OpenRead   21230 k(3,nil,nil,nil)  02

 150 Column 0 0 69   00
 151 Column 1 0 70   00
 152 Column 1 1 71   00
 153 SeekGE 21159   693  00
 154 IdxGT  21159   693  00
 155 IdxRowid   2172000
 156 Seek   1072000
 157 Column 104 67   00
 158 DecrJumpZero   68159   000
 159 Close  100 000
 160 Close  210 000
 161 Copy   6729000
 162 Column 1 0 14   00
 163 Column 0 0 15   00
 164 Column 1 1 16   00
 165 Column 1 2 17   00
 166 MakeRecord 141673   00
 167 SorterInsert   1173000
 168   Next   0 6 001
 169   Close  0 0 000
 170   Close  1 0 000
 171   Close  120 000
 172   OpenPseudo 227417   00
 173   SorterSort 11189   000
 174 SorterData 117422   00
 175 Column 224 18   00
 176 Column 225 19   00
 177 Column 226 20   00
 178 Column 227 21   00
 179 Column 228 22   00
 180 Column 229 23   00
 181 Column 221024   00
 182 Column 221125   00
 183 Column 221226   00
 184 Column 221327   00
 185 Column 221428   00
 186 Column 221529   00
 187 ResultRow  1812000
 188   SorterNext 11174   000
 189   Halt   0 0 000
 190   Transaction0 0 270  01
 191   TableLock  0 140 source_package_status  00

 192   TableLock  0 2 0 source_packages  00
 193   TableLock  0 7 0 bugs   00
 194   TableLock  0 180 nvd_data   00
 195   TableLock  0 5 0 debian_bugs00
 196   TableLock  0 4 0 package_notes  00
 197   TableLock  0 220 package_notes_nodsa  00

 198   String80 2 0 CVE-%  00
 199   String80 4 0 TEMP-% 00
 200   String80 7 0 sid00
 201   String80 9 0 stretch00
 202   String80 100 jessie 00
 203   String80 110 wheezy 00
 204   String80 120 squeeze00
 205   String80 60000
 206   Goto   0 1 000


 I have not run the query to completion using the new SQLite version.

 I will figure out a way to rewrite the query so that it runs
 reasonably fast again (which will address our immediate needs), but
 maybe there is something that can be fixed in the planner as well.
 ___
 sqlite-users mailing list
 sqlite-us...@mailinglists.sqlite.org
 http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



-- 
D. Richard Hipp
d...@sqlite.org

Re: [sqlite] Crippling query plan change between 3.7.13 and 3.8.10.2

[Richard Hipp]

On 5/28/15, Florian Weimer f...@deneb.enyo.de wrote:
 The Debian security tracker https://security-tracker.debian.org/
 uses an SQLite database to keep track of vulnerabilites and
 generate reports.

 We recently upgraded SQLite from 3.7.13 to 3.8.7.1 as part of an
 operating system upgrade and experienced a crippling query planner
 change.  I verified that the issue is present in 3.8.10.2 as well.


Thanks for the detailed bug report and for supplying a sample
database.  That made the problem much easier to analyze.

The problem is in the second subquery of the result set.  Here is a
simplification of the query:

SELECT
  st.bug_name,
  /* Problem in subquery below */
  (SELECT debian_cve.bug FROM debian_cve
WHERE debian_cve.bug_name = st.bug_name
ORDER BY debian_cve.bug),
  /* Problem in subquery above */
  sp.release
FROM
   source_package_status AS st,
   source_packages AS sp,
   bugs
WHERE
   sp.rowid = st.package
   AND st.bug_name = bugs.name
   AND ( st.bug_name LIKE 'CVE-%' OR st.bug_name LIKE 'TEMP-%' )
   AND ( sp.release = 'sid' OR sp.release = 'stretch' OR sp.release = 'jessie'
  OR sp.release = 'wheezy' OR sp.release = 'squeeze' )
ORDER BY sp.name, st.bug_name, sp.release, sp.subrelease;

Note that debian_cve is a VIEW not a table, and so we cannot do a
CREATE INDEX on debian_cve to fix this problem.

The reason that 3.7.17 is faster is that it is manifesting the view
into a transient table (one that exists for the duration of the query
only) and then automatically creating the appropriate index.  Version
3.8.x is just rerunning the subquery each time.  Bummer.  So we have a
query planner case that we need to work on

In the meantime, you can work around the problem by manifesting the
view yourself.  Before running your query, do:

   CREATE TEMP TABLE dx(
 bug_name,
 bug,
 PRIMARY KEY(bug_name,bug)
   ) WITHOUT ROWID;
   INSERT INTO dx(bug_name,dx) SELECT bug_name, dx FROM debian_cve;

Then use the dx table in place of debian_cve in your query.  Then
DROP TABLE dx after the query.

Version 3.7.17 was basically doing the above for you automatically.
Version 3.8.x is not, unfortunately.  Until we can get 3.8.x fixed and
get the fix into circulation, I suggest that you deal with this by
manifesting the view manually as shown above.



-- 
D. Richard Hipp
d...@sqlite.org


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALwJ=mzxr6xpanxqrmmvdyp2kpk5qnwhc0mucxydzpq7sgv...@mail.gmail.com

Re: [sqlite] Crippling query plan change between 3.7.13 and 3.8.10.2

[Richard Hipp]

On 5/28/15, Richard Hipp d...@sqlite.org wrote:

 In the meantime, you can work around the problem by manifesting the
 view yourself.

Another temporary work-around is to run the following C-langauge API
when the process first starts up (or at any other time prior to
running the query that is not performing well):

   sqlite3_test_control(SQLITE_TESTCTRL_OPTIMIZATIONS, 0x100);

Doing so will disable the specific optimization that seems to be
causing your performance problems.

Another work-around is to use the latest snapshot of SQLite on the
https://www.sqlite.org/download.html page and then add the ALL
keyword to the offending subquery.  Like this:

SELECT
  sp.name, st.bug_name,
  (SELECT cve_desc FROM nvd_data WHERE cve_name = st.bug_name),
  (SELECT ALL debian_cve.bug FROM debian_cve
  ------   Add this keyword.
WHERE debian_cve.bug_name = st.bug_name
ORDER BY debian_cve.bug),
  sp.release,
  sp.subrelease, ...

SELECT ALL means exactly the same thing as just SELECT in standard
SQL, but hardly anybody ever uses the ALL keyword.  So, for the time
being, SQLite has commendeered that syntax as a hint that the subquery
in the FROM clause (the debian_cve VIEW here) should be manifested
into a transient table rather than run incrementally by a co-routine.
This is an experimental hint and might well disappear before the next
official release, but if you want to help us experiment with it, that
would be great.

-- 
D. Richard Hipp
d...@sqlite.org


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALwJ=MxvAittjMokbuAWzZLXu6O_mRY=as8sq_c0+o3ptpe...@mail.gmail.com

Bug#761859: prototype ready

[Richard Hartmann]

On Wed, Feb 25, 2015 at 10:36 AM, Raphael Hertzog hert...@debian.org wrote:

 Release is a general concept that includes multiple respositories.
 And in repositories you have finer-graind data by real repositories.

That's what I was aiming for, yes.

Sorry, I had a draft in my phone, but didn't send that to not create
confusion with bad quoting.


Richard


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAD77+gScera29rJpifGzHTruF_LHqosD5E+SMtiqNyRmMT=q...@mail.gmail.com

Bug#761859: prototype ready

[Richard Hartmann]

On Mon, Feb 23, 2015 at 2:59 PM, Holger Levsen hol...@layer-acht.org wrote:
 surely. I just wasn't sure whether this should be done on the security-tracker
 side or by it's users... or I could provide two versions: json-full and json(-
 aggregated) - do you think that would be useful?

To clarify, I replied to this mail and meant the part above.

I see value in both having this is fixed in suite X and in this is
fixed in those subsets of suite X.

Depending on your layout, you don't really need two different JSON
files, though.


Richard


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAD77+gTZz6VjhDY71=ge7_sCoMSjbK3aA9k=ydgwbrosdvz...@mail.gmail.com

Re: Unverifiable Signature on Debian Security Advisory Emails

[Richard van den Berg]

 You can also use the finger interface at db.debian.org:

 finger seb/k...@db.debian.org

The 90's called: they want their finger back. ;-)  It seems RFC 1288 was
never updated for TLS support.
https://www.debian.org/events/keysigning points to
http://keyring.debian.org/ which should be the defacto place to look for
Debian PGP/GPG keys. It even mentions the finger interface.

-- Richard

Re: streql - Constant-time string comparison

[Richard van den Berg]

On 28-10-14 20:59 , Riley Baird wrote:
 As far as I can tell, your code ensures that even if the strings are of
 different length, an equality calculation should be performed anyway,
 however returning 0, on the grounds that this would make it more
 difficult for an attacker to know that the two strings entered were of
 different lengths. Is this right?

Pardon my ignorance, but how much more difficult does it actually become
to determine the two inputs are of different length? In the original the
function returns right away if xlen != ylen. If the attacker can control
one of the inputs (say x), the change proposed by Joel will cause the
time of the compare to increment when xlen in increased until xlen ==
ylen. If this can be observed with enough precision the same objective
can be achieved.

-- Richard



--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5450ab6e.1080...@vdberg.org

Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Richard van den Berg]

On 21 sep. 2014, at 20:29, W. Martin Borgert deba...@debian.org wrote:
 If a package would change by adding another signature, then this
 would invalidate previous signatures.

Package formats like apk and jar avoid this chicken and egg problem by hashing 
the files inside a package, and storing those hashes in a manifest file. 
Signatures only sign the manifest file. The manifest itself and the signature 
files are not part of the manifest, but are part of the package. So a package 
including it's signature(s) is still a single file.

Richard

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/8ce64b3d-6269-47a6-8cf2-5ecaa631b...@vdberg.org

Re: Debians security features in comparison to Ubuntu

[Richard van den Berg]

Joel Rees wrote On 17-05-14 03:19:

He gave me a link to the following site: 
https://wiki.ubuntu.com/Security/Features

None of the meaningful items in that list are unavailable on Debian, and
the defaults are reasonably secure in Debian.


I might be misinterpreting your definition of meaningful, but I have been looking for a public 
entropy source for my Debian system for quite a while. If you can point me to the Debian equivalent 
of pollinate and https://entropy.ubuntu.com/ that would be highly appreciated.


Kind regards,

Richard


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5377818b.3050...@vdberg.org

Re: Debians security features in comparison to Ubuntu

[Richard van den Berg]

Joel Rees wrote On 17-05-14 18:20:
Hmm. Early boot has problems getting enough randomness (for what?), 


To seed the kernel random number generator.

so let's go get some randomness from a server somebody in the Ubuntu project set up. 


I never said it was a great solution, but the lack of good quality entropy on headless (virtual) 
Linux systems is a real problem. I merely asked if the Debian project provides something similar, or 
hopefully better.


Kind regards,

Richard


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5377b3e9.3080...@vdberg.org

Re: Debians security features in comparison to Ubuntu

[Richard van den Berg]

Emmanuel Thierry wrote On 17-05-14 18:37:

Isn't it a better idea to use local entropy generators such as haveged instead 
of online ones ?


Haveged is great, but IMHO it cannot replace a hardware PRNG.


I'm quite disturbed about using a online (and moreover third-party) service to 
improve security of a local system. In my sense, this requires a huge level of 
trust towards the considered service.


I agree with you, but one can argue that increasing the entropy of a system by using an online 
service provided by the same organization that distributes the software of that system does not 
decrease the overall security of that system.


Kind regards,

Richard


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5377b5dd.8010...@vdberg.org

Re: goals for hardening Debian: ideas and help wanted

[Richard van den Berg]

 I suggest it might be better if exploits were each given a quick/approximate
 ranking in terms of severity (and if the severity is unknown it could be
 assigned a default median ranking), so that the algorithm you mention wouldn't
 just add number of unplugged exploits, but add them by weight

That is a good idea. The Common Vulnerability Scoring System was invented for 
this purpose:  http://en.wikipedia.org/wiki/CVSS

Kind regards,

Richard

--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/7f6371fd-0ee0-4f36-8f36-7736f65e7...@vdberg.org

End-user laptop firewall available?

[Richard Owlett]

I chose phrasing of subject line to emphasize some peculiarities 
of my needs.


End-user emphasizes:
  - I am *NOT* an expert
  - my system is never intended to be a server

Laptop indicates:
  - small standalone system intended to operate primarily 
*WITHOUT* any networking


When connected to internet it will be:
  - primarily for browsing, email, Usenet
  - occasionally used for downloading small files using HTTP 
*NOT* (never?) FTP


The fly in ointment will be:
   The typical internet connection will be with a USB dial-up modem.
   When I desire to browse complex website or download a large 
set of files,

 I will carry it to a local library and use a WiFi connection.

A couple months of reading has left me confused as to a suitable 
firewall.


Any help/direction appreciated.





--
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/52a35302.8080...@cloud85.net

Suggestion for http://www.debian.org/security/faq or http://www.debian.org/security/

[Richard Owlett]

Being new to Debian (and *nix generally) I went looking for 
information before going online with my new install. I expected 
links for guidance at http://www.debian.org/security/faq /or 
http://www.debian.org/security . Both seems to be focused on 
internals than interaction with outside world.


I would suggest a list of links such as:
http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO
http://www.tldp.org/HOWTO/Firewall-HOWTO.html
http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html

Are there Debian specific pages I should be looking at?

Thank you.



--
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/5270ed27.1050...@cloud85.net

Re: Suggestion for http://www.debian.org/security/faq or http://www.debian.org/security/

[Richard Owlett]

Iñaki Martinez de Ilarduya wrote:

The debian documentation has some extensive information about
securing your machine, with emphasis on servers:

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

I have used it as a guide several times, and consider it really
helpful.

Regards.


The table of contents looks like what I may need.
I do not intend to run a server. In fact some of my motivation 
was to make sure I did not do so unintentionally.

Thank you





On 30/10/13 12:27, Richard Owlett wrote:

Being new to Debian (and *nix generally) I went looking for
information before going online with my new install. I expected
links for guidance at http://www.debian.org/security/faq /or
http://www.debian.org/security . Both seems to be focused on
internals than interaction with outside world.

I would suggest a list of links such as:
http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO
http://www.tldp.org/HOWTO/Firewall-HOWTO.html
http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html

Are there Debian specific pages I should be looking at?

Thank you.









--
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/5271065f.1080...@cloud85.net

Re: process to include upstream jar sig in Debian-generated jar

[Richard van den Berg]

On 29 aug. 2013, at 09:39, Florian Weimer f...@deneb.enyo.de wrote:

 How would you tell a legitimate security update from a version that
 lacks a signature for other reasons?

If you are worried about a non-official/malicious update for the package, the 
.deb will still need to have a proper signature. The discussion here is the 
signature on the jar file that is read/verified by the jre. 

-- Richard


--
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/4dedc154-c4cc-4ded-86ec-373b760de...@vdberg.org

CVE-2013-2266 fix for bind9 in stable?

[Richard van den Berg]

Thanks a lot for the quick fix. Will bind9 9.7.3.dfsg-1 in stable also be 
fixed? I don't see any reports on http://www.debian.org/security/#DSAS and 
http://lists.debian.org/debian-security-announce/2013/threads.html

Kind regards,

Richard van den Berg

RE: [SECURITY] [DSA 2327-1] libfcgi-perl security-update

[Lustick, Richard]

Please remove me from this email. 


Richard Lustick
EchoStar Broadcasting Corporation
UPL- Systems Engineering
Staff DBA
(307) 633-5313

-Original Message-
From: Nico Golde [mailto:n...@debian.org] 
Sent: Monday, October 24, 2011 12:17 PM
To: debian-security-annou...@lists.debian.org
Subject: [SECURITY] [DSA 2327-1] libfcgi-perl security-update
Importance: High

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA-2327-1secur...@debian.org
http://www.debian.org/security/ Nico Golde
Oct 24th, 2011  http://www.debian.org/security/faq
- --

Package: libfcgi-perl
Vulnerability  : authentication bypass
Problem type   : remote
Debian-specific: no
Debian bug : 607479
CVE IDs: CVE-2011-2766

Ferdinand Smit discovered that libfcgi-perl, a Perl module for writing FastCGI 
applications, is incorrectly restoring environment variables of a prior request 
in subsequent requests.  In some cases this may lead to authentication bypasses 
or worse.


The oldstable distribution (lenny) is not affected by this problem.

For the stable distribution (squeeze), this problem has been fixed in version 
0.71-1+squeeze1.

For the testing distribution (wheezy), this problem has been fixed in version 
0.73-2.

For the unstable distribution (sid), this problem has been fixed in version 
0.73-2.

We recommend that you upgrade your libfcgi-perl packages.

Further information about Debian Security Advisories, how to apply these 
updates to your system and frequently asked questions can be found at: 
http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6lq34ACgkQHYflSXNkfP89PACffGjDkG63EMaUzQopBGp2w5nk
NyQAn1GE45ffdISzrvv2QGRwmSsdYrTH
=/1RH
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111024181630.ga23...@ngolde.de




--
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/d61c0c65d3dfa34890fe68a51adf418a1407170...@echoexcc1.sats.corp

RE: [SECURITY] [DSA 2222-1] tinyproxy security update

[BEN ALEYA Richard]

unsubscribe 


Cordialement, your sincerely,
 
European Parliament
 
Richard BEN ALEYA

-Original Message-
From: Moritz Muehlenhoff [mailto:j...@debian.org] 
Sent: 20 April 2011 19:16
To: debian-security-annou...@lists.debian.org
Subject: [SECURITY] [DSA -1] tinyproxy security update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

-

-
Debian Security Advisory DSA--1
secur...@debian.org
http://www.debian.org/security/Moritz
Muehlenhoff
April 20, 2011
http://www.debian.org/security/faq
-

-

Package: tinyproxy
Vulnerability  : incorrect ACL processing
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2011-1499
Debian Bug : 621493 

Christoph Martin discovered that incorrect ACL processing in TinyProxy, 
a lightweight, non-caching, optionally anonymizing http proxy could 
lead to unintended network access rights.

The oldstable distribution (lenny) is not affected.

For the stable distribution (squeeze), this problem has been fixed in
version 1.8.2-1squeeze1.

For the unstable distribution (sid), this problem has been fixed in
version 1.8.2-2

We recommend that you upgrade your tinyproxy packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2vFKcACgkQXm3vHE4uylo6pwCgtCVFoknYhvnWAyE16T8OaQ52
teEAoKjVuBWm802IODvSl8oz5I9Znbf4
=BXfn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to
debian-security-announce-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110420171613.GA3456@pisco.westfalen.local



Ce message contient des informations confidentielles à l'intention exclusive du 
destinataire. Il ne peut être utilisé, divulgué ou copié de quelconque façon 
que ce soit par une personne autre que le destinataire désigné. Si vous n'êtes 
pas le destinataire désigné, merci de contacter l'expéditeur et d'effacer ce 
message. L'expéditeur de ce message n'est pas mandaté à représenter le 
Parlement européen. Dès lors, ce message ne constitue pas nécessairement le 
point de vue officiel du Parlement européen, ni un engagement juridique 
opposable à ce dernier.
This message contains confidential information intended solely for the 
attention of the named addressee. It may not be used, disclosed or copied in 
any way whatsoever by anyone else than the intended addressee. If you are not 
the intended addressee, please contact the sender and delete this message. The 
sender of this message is not authorized to represent the European Parliament 
and therefore this message does not necessarily reflect the official position 
of the European Parliament and is not legally binding upon it.


--
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/73eb14e0f1108b47a648477f8fd3ac880443b...@emailbrusv23.ep.parl.union.eu

Re: [SECURITY] [DSA 1653-1] New Linux 2.6.18 packages fix several vulnerabilities

[Richard Hartmann]

On Wed, Oct 15, 2008 at 02:08, dann frazier [EMAIL PROTECTED] wrote:

 Its correct in the archives - maybe an issue on your end?
  http://lists.debian.org/debian-security-announce/2008/msg00245.html

I received:

apt-get update
   will update the internal database
apt-get upgrade
   will install corrected packages

so I also suspect this an issue with Swale's sytem.


Richard


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

Re: [SECURITY] [DSA 1615-1] New xulrunner packages fix several vulnerabilities

[Richard Hartmann]

On Thu, Jul 24, 2008 at 01:36, Michael Gilbert
[EMAIL PROTECTED] wrote:

 wouldn't it be better to send this person a warning?  i'm sure it was
 just an honest mistake.  it seems rather harsh to purge them from the
 mailing list without giving them a fair chance to remedy their
 mistake.

In theory, yes. In practice, the very definition of an away notifier means
that they will not be able to do anything about it, any time soon. Thus,
we will still receive their messages.
As re-subscription is easy to do, and even if it is a honest mistake on
their side, it makes sense to boot them.


Richard


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

Re: [SECURITY] [DSA 1615-1] New xulrunner packages fix several vulnerabilities

[Richard Hartmann]

(Replying to list for your benefit)

On Thu, Jul 24, 2008 at 02:16, Jim Popovitch [EMAIL PROTECTED] wrote:

 Also, IMHO (since this post will possibly generate more)  un-subs
 should also occur for people who use reply-all to a list, such as this
 one, that almost guarantees the poster being replied to will receive
 two copies. ;-)

http://www.unicom.com/pw/reply-to-harmful.html vs
http://www.metasystema.net/essays/reply-to.mhtml
is like vim vs emacs :)


Richard


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

Re: [SECURITY] [DSA 1615-1] New xulrunner packages fix several vulnerabilities

[Richard Hartmann]

On Wed, Jul 23, 2008 at 23:41, Bob Tanner [EMAIL PROTECTED] wrote:


 Please unsubscribe [EMAIL PROTECTED] from the mailing list.

The correct place to report this is [EMAIL PROTECTED]
Just forward one of the mails and ask that they remove him. I
just did that, so he should be gone shortly.


Richard


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

Re: broken updates just now clamav ....

[Richard A Nelson]

On Fri, 30 May 2008, Stephen Gran wrote:


Good luck, and please feel free to tell upstream this was an unhelpful
change.


hrm,  I wonder if/when the other (3rd party) dbs will get upgraded:
http_source_urls=
   http://www.sanesecurity.com/clamav/phishsigs/phish.ndb.gz
   http://www.sanesecurity.com/clamav/scamsigs/scam.ndb.gz
   http://clamav.securiteinfo.com/vx.hdb.gz
   http://www.malware.com.br/cgi/submit?action=list_clamav,fetch_interval=86400,


Since I'm going to be out of town this weekend, I'm holding off on the
clamav update 'til I'm back and can watch it - but the others are pulled
from cron daily
--
Rick Nelson
 Why use Windows when you can have air conditioning?
 Why use Windows, when you can leave through the door?
-- Konrad Blum


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

Ihanot received any response in regards the funds transfer Re urgently

[RICHARD OPENE]

¡Tengo nueva dirección de correo!Ahora puedes escribirme a: [EMAIL PROTECTED]



- RICHARD OPENE

Re: Problems after sendmail security upgrade

[Richard A Nelson]

On Mon, 3 Apr 2006, Emmanuel Halbwachs wrote:


For some reasons, the admins didn't configure sendmail the Debian
way and didn't use the queue aging feature in
/etc/mail/sendmail.conf.

- is it mandatory to use /etc/mail/sendmail.conf?


No, not at all


- is there a way to manually configure sendmail the classical way
 without using the Debian configuration wrappers but cleanly against
 the package upgrade? (no offense, just for people accustomed to
 other OS like *BSD)


set this variable in /etc/mail/sendmail.conf
HANDS_OFF=Yes;

After setting that, the scripts become non-functional; any and all
changes must be done manually

--
Rick Nelson
Microsoft is a cross between the Borg and the Ferengi.  Unfortunately,
they use Borg to do their marketing and Ferengi to do their
programming.
-- Simon Slavin


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

Re: Problems after sendmail security upgrade

[Richard A Nelson]

On Fri, 24 Mar 2006, Emmanuel Halbwachs wrote:


Emmanuel Halbwachs a ?crit (Fri, Mar 24, 2006 at 06:57:43PM +0100) :

- after the upgrade : in some cases (more on this below), incoming
  mail goes to /var/spool/mqueue/daily and is stuck there


OK, the problem was on our side:

/etc/cron.d/sendmail has been tailored to our needs and has been
reverted to a standard Debian one by the upgrade.

Very sorry for the noise and thanks for your collaboration.


Can you mail me more details... there is support in
/etc/mail/sendmail.conf to automagically support the type of queue aging
that you are doing...


--
Rick Nelson
* BenC wonders why he has upgraded to 3.3.5-1 before teh X maintainer

Re: rm files owned by root?

[Richard Atterer]

On Wed, Dec 29, 2004 at 08:22:08PM +0100, dekkker wrote:
 It asks if I want to remove this file, since it's write protected. If I
 say y, then the file gets deleted. But it shouldn't be! Should it? 

As the others have said, this behaviour is to be expected.

If your filesystem is ext2 or ext3, you can achieve what you want by using
chattr as root to set the file's immutable bit. According to the
manpage:

  A file with the `i' attribute cannot be modified: it cannot be deleted or
  renamed, no link can be created to this file and no data can be written
  to the file.  Only the superuser or a process possessing the
  CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

Is something similar also available for other filing systems?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: preserving sendmail configuration security hacks

[Richard A Nelson]

On Wed, 10 Nov 2004, Duncan Simpson wrote:

 I can put the rulesets Local_check_* rulesets in the LOCAL_RULESETS in
 sendmail.mc and delete the blank ones make sendmail.cf generates
 manually but this is suboptimal. Is there a way of writing the
 sendmail.mc file so the extra rules in the Local_check_* rulesets
 appear.

I do stuff like this all the time (in sendmail.mc, or include):
LOCAL_RULESETS
# Allow etrn,expn,vrfy from anyplace allowed to relay through us
SLocal_check_commands
...
# No pause for port 587(MSP) as authentication is required
SLocal_greet_pause
...

The last case does cause two occurances of Slocal_greet_pause... but
unlike the Bat book V2 (still gotta get V3), sendmail doesn't complain
- and does the right thing.

I'd be happy to look over you setup if you'd like...  If you've got
anything that might be generally applicable, I'd love to merge it into
what I'm putting together... a set of hacks to increase security and
simplify things as much as possible.

-- 
Rick Nelson
What you end up with, after running an operating system concept through
these many marketing coffee filters, is something not unlike plain hot
water.
(By Matt Welsh)


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

Re: [SECURITY] [DSA 563-1] New cyrus-sasl packages fix arbitrary code execution

[Jérôme RICHARD]

Hello,
After upgrading libsasl7, slapd does a segmentation fault and don't  
start !!

I had to downgrade libsasl7 to fix it !
Regards,
Jerome.
Le 12 oct. 04, à 14:52, Martin Schulze a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
-  
--- 
---
Debian Security Advisory DSA 563-1  
[EMAIL PROTECTED]
http://www.debian.org/security/ Martin  
Schulze
October 12th, 2004   
http://www.debian.org/security/faq
-  
--- 
---

Package: cyrus-sasl
Vulnerability  : unsanitised input
Problem-Type   : local
Debian-specific: no
CVE ID : CAN-2004-0884
Debian Bug : 275498
A vulnerability has been discovered in the Cyrus implementation of the
SASL library, the Simple Authentication and Security Layer, a method
for adding authentication support to connection-based protocols.  The
library honors the environment variable SASL_PATH blindly, which
allows a local user to link against a malicious library to run
arbitrary code with the privileges of a setuid or setgid application.
For the stable distribution (woody) this problem has been fixed in
version 1.5.27-3woody2.
For the unstable distribution (sid) this problem has been fixed in
version 1.5.28-6.2 of cyrus-sasl and in version 2.1.19-1.3 of
cyrus-sasl2.
We recommend that you upgrade your libsasl packages.
Upgrade Instructions
- 
wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.
If you are using the apt-get package manager, use the line for
sources.list as given below:
apt-get update
will update the internal database
apt-get upgrade
will install corrected packages
You may use an automated update by adding the resources from the
footer to the proper configuration.
Debian GNU/Linux 3.0 alias woody
- 
  Source archives:
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/cyrus- 
sasl_1.5.27-3woody2.dsc
  Size/MD5 checksum:  711 5eef2264f52bb4f3dc2a655285a889d2
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/cyrus- 
sasl_1.5.27-3woody2.diff.gz
  Size/MD5 checksum:40375 35007ca458f24aedebc3a651bbb5f9d2
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/cyrus- 
sasl_1.5.27.orig.tar.gz
  Size/MD5 checksum:   528252 76ea426e2e2da3b8d2e3a43af5488f3b

  Alpha architecture:
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
dev_1.5.27-3woody2_alpha.deb
  Size/MD5 checksum:76260 6263d2d53f5cc606d11c372d078ffc63
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
digestmd5-plain_1.5.27-3woody2_alpha.deb
  Size/MD5 checksum:19100 8a901b0282fbd4ced40b820a961b01c0
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
modules-plain_1.5.27-3woody2_alpha.deb
  Size/MD5 checksum:14944 dd2ce3541cd52e2564e829b9616cba76
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/ 
libsasl7_1.5.27-3woody2_alpha.deb
  Size/MD5 checksum:   172284 759030ca07a99ac03d8243dca9c2cad1
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/sasl- 
bin_1.5.27-3woody2_alpha.deb
  Size/MD5 checksum:13414 076ea2b666ab7dd47de390829c9b59ab

  ARM architecture:
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
dev_1.5.27-3woody2_arm.deb
  Size/MD5 checksum:70148 e4d6ea105d776178620d7b12c4a0896a
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
digestmd5-plain_1.5.27-3woody2_arm.deb
  Size/MD5 checksum:15040 9691c34f18d88e24037dcbb1606156e9
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
modules-plain_1.5.27-3woody2_arm.deb
  Size/MD5 checksum:12452 e42407c240af8914be263deda7790cb0
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/ 
libsasl7_1.5.27-3woody2_arm.deb
  Size/MD5 checksum:   165868 4091e9262e8603612c1a3515f907fd6b
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/sasl- 
bin_1.5.27-3woody2_arm.deb
  Size/MD5 checksum:10850 22d3bd0b8a64cf6b907ca268b55cb80d

  Intel IA-32 architecture:
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
dev_1.5.27-3woody2_i386.deb
  Size/MD5 checksum:65256 a56f4a88b5ff92ce7928cb73729044fd
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
digestmd5-plain_1.5.27-3woody2_i386.deb
  Size/MD5 checksum:13296 0b9d7f91fb9b0216098dc79b74530add
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/libsasl- 
modules-plain_1.5.27-3woody2_i386.deb
  Size/MD5 checksum:11750 ceaeb52a01badb855be07fa38cd90c4b
 
http://security.debian.org/pool/updates/main/c/cyrus-sasl/ 
libsasl7_1.5.27-3woody2_i386.deb
  Size/MD5 checksum:   162842 

Re: telnetd vulnerability from BUGTRAQ

[Richard A Nelson]

In the non-unix world, telnet is still a necessity :(

Yes, I have putty on *my* windows boxen...  But there are still
significant numbers of boxes that I use - MVS/VM (z/OS), W2k, etc.
that require me to allow directed telnet to my laptop/workstation.

Just because there is a H2 on the block, doesn't mean that the original
VW bug is now no longer needed...

-- 
Rick Nelson
Linux supports the notion of a command line or a shell for the same reason
that only children read books with only pictures in them. Language, be it
English or something else, is the only tool flexible enough to accomplish
a sufficiently broad range of tasks.
-- Bill Garrett


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

Re: telnetd vulnerability from BUGTRAQ

[Richard A Nelson]

On Sat, 25 Sep 2004, Rick Moen wrote:

 Quoting Richard A Nelson ([EMAIL PROTECTED]):

  Yes, I have putty on *my* windows boxen...  But there are still
  significant numbers of boxes that I use - MVS/VM (z/OS)...

 OpenSSH works on MVS.  See:
 http://www.stdnet.com/uploads/media/MOVEit-DMZ-Compatible-Clients.PDF.

Yes indeed, but MVS isn't an OS where mere mortals get to install
software...  So I'd most likely be stuck with only client support.

MVS is getting telnet-SSL support also - and I use that where I can

 , W2k, etc.

 Innumerable SSH implementations work on MS-Windows 2000.  See:
 http://linuxmafia.com/ssh/win32.html

I typically use cygwin on *MY* laptop, but when away from that -
I try not to install random software on other's boxen

 For others, please see:  http://linuxmafia.com/ssh/

  ...that require me to allow directed telnet to my laptop/workstation.

 Maybe, but not the ones you mentioned.

ok, I should've said to/from my laptop (and occaisionally other boxen)

The point remains that while telnet/ftp should be treated as deprecated
when feasible, sometimes there just aren't alternatives... and even
stock w98 had a built-in telnet client.

-- 
Rick Nelson
Besides, its really not worthwhile to use more than two times your physical
ram in swap (except in a select few situations). The performance of the system
becomes so abysmal you'd rather heat pins under your toenails while reciting
Windows95 source code and staring at porn flicks of Bob Dole than actually try
to type something.
-- seen on c.o.l.development.system, about the size of the swap space


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

Re: Debian Hardened project (question about use of the Debian trademark)

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lorenzo Hernandez Garcia-Hierro wrote:
| Hi John,
|
| El vie, 17-09-2004 a las 19:04, John Richard Moser escribió:
|
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|
|
|Lorenzo Hernandez Garcia-Hierro wrote:
|| Hi,
||
|
|[...]
|
[...]
|I prefer directly hardening Debian with things that don't get in the way
|of the user.  That's what I was going on about a month ago with PaX (I'm
|still working with that, just waiting until after Sarge).  As long as
|the user doesn't have to see it, it can and I think should go into
|mainline Debian.
|
|
| Debian Hardened is not a Debian-based distro, i said that it is a
| hardened tree of packages and kernels that should replace (with user
| election or by default, for example asking the user during the
| installation if he wants to have extra security or if it will be used
| for critical uses).
| I think the same as you, it must go in the Debian mainline.
Yes yes I understand you're a subproject.
The kernel can be elective, but some of the work that gets done will
require either a separate copy of the entire debian tree, or will
require that the changes go into mainline.  Building binaries with SSP
and PIE is like building binaries using gcc 2.95 or gcc 3.4:  the
decision won't directly affect the users' experience, and it can't be
made an option to the user without a lot of extra storage space on the
mirrors and a lot of work maintainer side.
|
|  Debian.
|   -
|   |   |
| ^ ^
|   Kernel packages Software Packages.
|   --|---  --|-
|   Not Hardened  | HardenedHardened  | Not hardened.
|   --  
|  \apt-get install harden   /
| \  debian-hardened  /
|\ /
||   *KISS*|
|  |Keep it simple,stupid|
|\-/
|
|
Debian
|- Kernels
||- Hardened (PaX enabled, SELinux enforcing, etc)
||- Non-Hardened
|- Maintenance
||- Compiler used
|||- Options used
- Optimizations
|- -O2
- Security options
|- -fstack-protector
|- -fpie
||- Packaging
|||- Mirrors
We have the same goals basically; but I don't think that for most of
this there is room for an 'apt-get install hardened' or whatever.  The
changes are too integral to be covered by a handfull of packages; you
would need an entire mirror of all Debian packages with all hardening
features.
Now, if you're after creating SELinux, GRSecurity, and RSBAC policies,
those can be controlled by boot time parameters to the kernel.  Also, as
long as they're off, there's no need for the user to install the policy.
~ Those are the types of things that can *feasibly* be made optional,
because they don't require a recompile.
|My point here is, you mention advanced users and sysadmins; but I'm
|focused on people who are too stupid to remember how to save a document
|in MS Word in RTF format instead of .doc.
|
|
| Look above.
| People is not stupid, my father is not stupid because he doesn't know
| which Debian means...people want to do simply their things in their
| live, that's usability and we can't make people start learning, for
| example, LaTeX,TeX,whatever you want... if they only want to write poems
| on a page, or teach maths to their children.
|
You need to get out more; a *lot* of people are stupid.  ;)
Don't go on the assumption that people know wtf they're doing.  I know
wtf I'm doing.  I could rebuild a Debian Sarge installation as it exists
today with all hardening features.  It's still a pain in the ass, and I
don't want to be bothered.  Even when the target isn't an idiot, he may
still prefer to have the work done for him; otherwise he'd be using LFS.
|
|[...]
|| if
|| you a hardened binary (+SSP/ProPOlice and a library to trace the BOF
|| conditions) in a hardened environment (hardened kernel and RBAC/RSBAC
|| policies) it will be not dangerous as having a simple Debian!
|
|Umm, update anyway dude.  It's still a DoS attack.
|
|
| Buffer Overflow conditions in the stack will be stopped by ProPolice
| (__guard ...).
|
Yes and then the program halts and gets SIGABRT.  Do you not know what a
DoS attack is?
[...]
|
|
| Yes, ProPolice/SSP is a GCC extension.
| Rebuild?
| Ok, i'm a Gentoo user, mea culpa :P, but i thought that i din't say to
| recompile packages, i said make binary packages in a different branch.
| (Again, the theme of the graphic i wrote above) .
|
I don't believe that forking a Debian package for these protections is
appropriate.  They don't harm anything; anything that they do harm of
course you can't protect anyway.  There's no point in separating the two
bases, and no point in wasting tons of mirror space and maintainer
effort

Re: Debian Hardened project (question about use of the Debian trademark)

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lorenzo Hernandez Garcia-Hierro wrote:
[...]
Good, at least you understand that :)
|
|Yes and then the program halts and gets SIGABRT.  Do you not know what a
|DoS attack is?
|
|[...]
|
|
| Duty of Shame ?
| OK, leaving the Fun Mode off...
| (here, Spain, it's 23:00 and 'm tired, i've started the school this week
| and its the last course to get in the high school, two years more and
| then the university...i must work harder! ;-D )
| ProPolice sends messages to /var/log/messages and also to the last
| 4kbytes of dmesg, or whatever you have selected to be used by syslogd.
| The idea is simple: ANY package will be more secure compiled with PIE 
| SSP/PPolice than compiled itself without any other extension (in this
| case, security related).
|
Yes but the point is that while you deflect the intrusion, I can still
rape the program raw and continually force it to terminate.
Also, in cases such as Apache, which populates the system with fork()s
of itself, the address space isn't rerandomized; the SSP canary isn't
rerandomized; and overall it's very difficult to prevent an attacker
from rabidly drilling into the skin of these daemons and going until he
hits both of these.  This can be done in probably an hour or so.  In
these events, SSP and ASLR become like passwords:  They deflect attacks
nicely, but can be directly exploited by an attacker with enough time.
Imagine having a vulnerable Xchat too.  Attacker can't come in; but you
can NOT stop some jackass from just {DCC SEND @*Y^! 1
! ! ! ! ! ! ! } and taking you down whenever he wants.
It's less pressing when you have these; but you do still need to get up
to date with security patches.
|
[...]
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBS2MUhDd4aOud5P8RArSMAJ9YB5zV2Ps2vGWrdxrRyV17KO6teACfc6bF
mzY9u1B4AGpNuAgL34V2/B4=
=iR76
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [OT] Is calculating an MD5 hash of a Rjindael encrypted block and it's key insecure?

[Richard Atterer]

Hello,

here's my ¤0.02... note that I would not call myself a crypto expert 
either.

On Thu, Aug 12, 2004 at 11:54:14AM +0200, Marcel Weber wrote:
 My solution is a mod_perl module, that catches every request before the
 authentication module and supplies the credentials automatically. This
 works with ANY apache authentication modules using basic authentication. 

This strikes me as a weird solution. What's wrong with setting the cookie
lifetime higher, so that people only need to log in e.g. once a day? Hmm, 
presumably the web application is closed-source or un-hackable due to other 
reasons...

 The cookie has a limited lifetime, is bound to the client's IP address 
 and is AES256 encrypted, with a server side stored encryption key.

If I understand this correctly, you have one central server-side AES key
which never changes. From a security design POV, this is bad - a malicious
user might be able to turn your Apache module into an oracle; he can supply
a huge number of fake user/password strings and analyse the encrypted
cookie's contents, with an intent of cracking the central key.  I see no
immediate way for him to succeed in this, or indeed a way to make use of
the master key, but it does not feel good.

An alternative approach to the whole problem could be to use a server-side 
database of user/password data. The cookie could contain just a random 
string of bits to reference the right database entry.

 I discovered, that if I changed this encryption key, the module would not
 return, as it could not decypher the credentials. Furthermore someone
 could send an invalid cookie which would cause some DoS attack. So I
 added a checksum over the encrypted credentials and the key itself. This
 checksum has the form of an md5 hex checksum and is checked before the
 decyphering of the credentials takes place.

Again, this feels wrong if I think of abuse of the server as an oracle. 
Maybe consider encrypting the checksum with the rest of the data, i.e.
$c = encrypt( $s . md5($s) )

 I'm no cryptographic expert, so I'm asking this: Using AES256 in CBC 
 mode, if I have a key $k and a string $s representing the credentials, 
 that's encrypted with this key and if I calculate the checksum following 
 this method
 
 $c = md5_hex( $s.$k );
 
 Does $c compromise the security of the the encrypted credentials, resp. 
 the key $k? 

For all practical purposes, this should be fine. For example, there are far
easier attacks if I were to have access to your intranet, like intercepting
the traffic between my victim users and your server via ARP poisoning,
persuading them to try logging on on my machine, or just bribing them. :)

But with my nitpicking-security-paranoia hat on, the solution is not ideal.

 This is important because $s and $c get stored in the cookie.

Why $s? Surely you'll only store $c in the cookie, otherwise there's no 
point in encrypting the data.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: [OT] Is calculating an MD5 hash of a Rjindael encrypted block and it's key insecure?

[Richard Atterer]

On Thu, Aug 12, 2004 at 01:56:53PM +0200, Marcel Weber wrote:
 Richard Atterer wrote:
 This strikes me as a weird solution. What's wrong with setting the
 cookie lifetime higher, so that people only need to log in e.g. once a
 day? Hmm, presumably the web application is closed-source or un-hackable
 due to other reasons...
 
 No, not at all. The apache authentication Module used is auth_ldap, 
 which in turn authenticates against a Windows 2000 AD Server. As 
 auth_ldap uses basic authentication (which basically means, that the 
 user has to enter his / her login / password everytime)

No, it doesn't mean that. Current browsers will cache the password, AFAIK
until the end of the session by default, and forever if you enable the
option Remember this password or similar.

 - No more credentials that are sent in plain over the internal network 
 (which is the case if you use basic authentication), except for the 
 initial login.

Hmm, but the initial time is enough... :-/ You will need to use SSL for 
that.

 The block size of the data to be encrypted has to come in chunks of 16
 bytes. I always append random numbers to the credentials, ip and time
 strings to the next 16 bytes before encryption. Like this, the attacker
 cannot know or guess all of the content of the encrypted data, can he?

This makes things more difficult for the attacker, yes. Presumably your
code adds no random padding if the data already has the right length, but
still...

 The trouble is, as far I figured out, that Crypt::Rjindael does not
 return, when you try to decrypt an encrypted string that's, a. damaged or
 b. encrypted with a different key. Don't know why.

This cannot be. Rijndael gets bits as input, and it outputs bits. The only
thing that will happen is that you'll get random-looking garbage if the
input is incorrect in some way. (I don't know what Crypt::Rjindael does.)

 Why $s? Surely you'll only store $c in the cookie, otherwise there's no
 point in encrypting the data.
 
 Ahem, well $s is encrypted and $c is only a md5 checksum for $s and $k. 

Sorry, I misinterpreted your message and thought that $s was not encrypted.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

PaX demo results, logs, reproduction data

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have completed an in-house test of a PaX demonstration.  The demo
includes the PaX patch; a patch I made to suppliment PaX with boot-time
selection of NX mode; a script `pax-flags` to mark binaries with
chpax/paxctl and execstack (to turn the executable stack bit,
PT_GNU_STACK, off); and a configuration script for pax-flags.
The process I followed was a three-phase process which involved 1)
running an unadultered Debian base on a non-PaX-patched 2.6.7 kernel
(kernel-sources-2.6.7-1); 2) Switching to a PaX-patched version and
demonstrating breakage, then demonstrating how flagging effectively
works around (and thus mutes) the incompatibilities; and 3) returning to
the same kernel used in (1) and running the marked binaries to show that
they are unaffected.
A full explaination is in the file:
http://pax.wooyd.org/pax.txt
The directory listing of
http://pax.wooyd.org/
contains the patches used; the logs of the three-phase test (large
amounts of output, you really have to search for my input prompts); the
pax-flags script (an ugly script at that); and a pax.conf for pax-flags
on x86.
It is interesting to note that I messed up in the middle of phase 2, and
had to actually track down what was triggering wine; I was pretty sure
already, but wanted to test out just -m on it anyway, so took the
chance.  This process took less than two minutes for me to complete.
Wine is a special case, and needs the -x flag because of the preloader.
~ This was not tracked down during the above noted flagging miss; I added
that at the end when I remembered the docs I read about the preloader.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBDBmzhDd4aOud5P8RAkhtAJ9mNrKbN9pVCkEjVv1twt2zUCEpUQCeJCwl
gOBAYzaOtae7+WnIdrMKkVQ=
=OXR6
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian (Demo setup)

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've got a chunk of data that can be used for a demo setup over here.  I
would like the help of any debian developers that would like to package
up a set of kernels and the scripts that come with this and place them
in a mini-repository, to give the devs a chance to decide if they want
to move PaX support into post-Sarge SID.
Note that this is only a skeletal demonstration.  A few packages, most
notably X, break because of PaX; this demo marks up these packages so
that they do not break.  The most notable effect will be that an
unmarked X will refuse to start when running a PaX kernel, while a
marked one will start fine.
Markings must be applied while the programs aren't in use (i.e. turn off
X before marking it; it'll turn itself off if you're in the PaX kernel :P).
It contains:
~ - PaX kernel patch for 2.6.7
~ - Patch on top of PaX which allows pax_default_nx= on kernel command
line, as well as /proc/pax_status
~ - A pax-flags script that uses /etc/pax.conf to mark up binaries
~ - An /etc/pax.conf
~ - A config-2.6.7-1-k7-pax configuration file for
kernel-sources-2.6.7-1-k7 with the above patches
The two patches patch cleanly to kernel-sources-2.6.7-1, a bit of fuzz
but no misses.
The pax-flags script and pax.conf are modified versions of the Gentoo
script and configuration from Gentoo Linux.  They're ugly, but they work
well enough for a demonstration.
The config file is for k7, but the PaX section can be duplicated into
other config files.  Note that until glibc is fixed as per bug #245563,
PAGEEXEC can NOT be enabled on x86, as it forces the vsyscall page to be
disabled.
SEGMEXEC is fine for a demonstration.  Once #245563 is fixed, PAGEEXEC
and SEGMEXEC can be fixed, with default to PAGEEXEC (except for k6-2),
adjustable via pax_default_nx={page|segm}exec on the command line.

Please read this IRC conversation:
bluefoxicy pipacs:  how hard would it be to add PT_PAX_FLAGS to an
existing binary?
pipacs it depends on what you've got in the ELF already
pipacs if you have a program header that you can 'recycle' then it's
trivial
pipacs prime candidate these days is PT_GNU_STACK ;)
bluefoxicy otherwise it's not so easy?
pipacs otherwise it's some real hacking on it, to extend the first
PT_LOAD segment downwards
pipacs that will force you to adjust all file offsets
pipacs that's some work
bluefoxicy pipacs:  the #debian folk don't seem to like the idea of
distributing binaries with PT_PAX_FLAGS, and were arguing that it
should be easy to have a tool that just adds the field
bluefoxicy and i'm like . . . there'd already be one if it was that
easy. . . .
pipacs it's normally not 'cos the program header table is not easily
extensible
pipacs 'cos there's no room in the file normally
bluefoxicy heh
bluefoxicy can I quote you on that some time later?
pipacs sure but i dunno what that helps
pipacs on one hand, presence of PT_PAX_FLAGS doesn't cause any trouble
bluefoxicy pipacs:  it helps me convince the debian devs to use a
patched binutils to build the system
pipacs on the other hand it's useful only under pax kernels
bluefoxicy yeah but it's not damaging under non-pax kernels, and
non-trivial to add later
pipacs so debian should first decide if they're interested in pax at all
pipacs well, debian is or will soon be using gcc 3.x
bluefoxicy I'm trying to get them interested in it (mandrake and suse
just ignored me), hence all the mailing list conversations.
pipacs that and a recent binutils will produce PT_GNU_STACK
pipacs so we can always reuse that
pipacs it's useless anyway under pax
pipacs i'll add support for such a conversion to paxctl
If Debian is interested in PaX, they should use PT_PAX_FLAGS.  This will
soon be possible by junking PT_GNU_STACK for PT_PAX_FLAGS via paxctl;
however, it is also possible to add the field by using a patched binutils.
Also, supporting PaX, although easy to demonstrate in a non-invasive
way, is a *VERY* invasive task distribution side.  Everything that can
be compiled ET_DYN (-fPIC -pie) should be; ideally, everything (except
certain programs like wine, which needs the wine preloader to load the
executable at a predetermined base) would be position independent.
Notice below:
[EMAIL PROTECTED] /data % file /bin/cat
/bin/cat: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
stripped
Once such support is figured out, it will be trivial for Debian's
developers to maintain the distribution (about as trivial as is now,
with the occasional bump when something suddenly doesn't want to compile
ET_DYN or needs to be marked up).  Thus, although it is invasive at the
start, it is fairly non-invasive to the continued maintainance process.
Debian should also decide if it will support an SSP base; the problem of
pie/ssp should be tackled in one sweep, since they're easy to identify:
~ pie problems will cause programs to fail to compile (cannot find
available register of class BREG or such); SSP problems will cause
programs to crash.  

Re: PaX on Debian (Kernel Settings)

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This post is also being forwarded to debian-kernel, as it contains the
appropriate kernel settings.  This is a continuation of the message from
the debian-security and debian-devel lists, archived at
http://lists.debian.org/debian-security/2004/07/msg00159.html
There is a recapitulation of the data from this thread at
http://lists.debian.org/debian-security/2004/07/msg00201.html
As noted, kernel settings have not yet been discussed.  Here, I will
discuss the settings I recommend for best compatibility, and what issues
PaX raises in kernel packaging.
It still hasn't been decided if Debian will actually supply a
PaX-enabled base, with ET_DYN binaries or even with PT_PAX_FLAGS in the
ELF headers (PaX binutils patch makes these) and appropriate markings to
prevent breakage under a PaX kernel.
If Debian is indeed going to support a PaX protected base, it will have
to supply a PaX kernel to make any use of it; however, it is possible to
supply a PaX kernel without the special base.  Things will break under
the PaX kernel without the support of the distribution to find and mark
these ahead of time; but it would still make an easy first step.  Users
should NOT by default use a PaX kernel image without a PaX base!
In either case, the below settings can be used most safely with PaX on
x86.  Notes about breakage and other architectures appear below; read
them if you intend to make any use of this.
|Security options  ---
|PaX  ---
|[*] Enable various PaX features
|   PaX Control  ---
| [*] Support soft mode
| [*] Use legacy ELF header marking
| [*] Use ELF program header marking
| MAC system integration (none)  ---
|   Non-executable pages  ---
| [*] Enforce non-executable pages
| [*]   Paging based non-executable pages
| [*]   Segmentation based non-executable pages
|   Default non-executable page method (SEGMEXEC)  ---
| [*] Emulate trampolines
| [*] Restrict mprotect()
| [ ]   Disallow ELF text relocations
|   Address Space Layout Randomization  ---
| [*] Address Space Layout Randomization
| [*]   Randomize kernel stack base
| [*]   Randomize user stack base
| [*]   Randomize mmap() base
| [*] Randomize ET_EXEC base
| ---   Disable the vsyscall page
The [ ]   Disallow ELF text relocations option must be disabled, else
certain programs won't work.  There is no way to disable this at runtime
that I am aware of.
MAC system integration (none)  --- can be set to Hook (I believe)
for certain SELinux patches or for other ACL systems; but this is beyond
the scope.  ACL systems are appropriate for Adamantix, but I do not
believe they are appropriate for Debian's standard distribution.
[*]   Paging based non-executable pages will FORCE Disable the
vsyscall page on on x86.  This breaks Debian's current glibc as per
Debian Bug #245563; however, this issue is fixed in upstream glibc (as
noted on the bug).  Patches should be ported back so that PAGEEXEC can
be used; and/or a newer glibc should be used on whatever Debian release
starts off with PaX.  This should not affect amd64 or other archs.
Archs with a hardware NX bit should use PAGEEXEC.  This includes AMD64
and PowerPC I believe, as well as many others (sparc, etc).
[*]   Segmentation based non-executable pages (SEGMEXEC), when used,
will halve the virtual address space available to a task.  Be wary.
A patch can be supplied that will make the Default none-xecutable page
method selectable at boot via a kernel command line option.
A big one here, it was found that PaX patches onto Debian's 2.6.7
patched kernel cleanly.  You may or may not supply PaX in your base
kernel patch set; however, it is encouraged that you supply *BOTH* a
PaX-enabled and PaX-disabled kernel.  Just putting N on 'enable
various PaX features' up there for the PaXless one should be sufficient.
There are various other patches that go well with PaX, such as the
obscurity patch (which NULLs out /proc/PID/maps to prevent basic
information leaking) and the pax_default_nx= patch.  It's up to you to
decide what you want if you're going to supply a more secure kernel image.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBsDuhDd4aOud5P8RAiKJAJ92Zam6Xho/nCYt0AEOAVVhm7j/0QCbBSRA
plOEaYP3i3KEhx2h2mgCt1o=
=8h/m
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|
|
| I'm interested in discussing the viability of PaX on Debian.  I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
|
|
|
| I think debian-kernel would be a better place to discuss this (at least,
| the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
| been very pleased with it.  I would love to be able to include it in
| debian 2.6 kernels, but we need to make sure that:
|
| a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
| I've also heard reports of various grsec problems on 2.6; I don't
know how
| many of those are PAX issues)
Did some digging.  pipacs said that PAGEEXEC force-enables the 'disable
vsyscall' option, so you'd be forced to use SEGMEXEC on x86 to avoid
#245563, if I'm reading this right.  On amd64, it should be fine; he
said that vsyscall is force disabled because having a high page
executable area will cause PAGEEXEC performance to fall through the
ground, due to the workings of the recent speed-up (which follows the
same method Exec Shield uses as a speed boost, and falls back to the old
way when that fails).  Because amd64 has hardware NX, there's no
emulation issue, thus I'm supposing no breakage due to vsyscall.
:  Tags added: fixed-upstream Request was from GOTO Masanori
:  [EMAIL PROTECTED] to [EMAIL PROTECTED] Full text available.
Fixed in upstream.  Either use an updated glibc in the next debian
release (I know there's no way you're going to suddenly shift STABLE to
PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
Debian's development model), or backport the changes to whatever glibc
you use.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBU97hDd4aOud5P8RAjRuAJ9k3EiS+zVnEFmLoCM8KnTOZehe8ACgh7FC
a9PyG2GbEkpMi17HlrUcyTY=
=3Mtk
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andres Salomon wrote:
| On Mon, 2004-07-26 at 14:37 -0400, John Richard Moser wrote:
|
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|
|
|Andres Salomon wrote:
|| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
||
|
| [...]
|
|Did some digging.  pipacs said that PAGEEXEC force-enables the 'disable
|vsyscall' option, so you'd be forced to use SEGMEXEC on x86 to avoid
|#245563, if I'm reading this right.  On amd64, it should be fine; he
|
|
| Yep, that's right.  I've talked to both ian and pipacs about it.
| Spender and pipacs both agree that upstream glibc fixes will work.
|
Cool.
| [...]
|
|:  Tags added: fixed-upstream Request was from GOTO Masanori
|:  [EMAIL PROTECTED] to [EMAIL PROTECTED] Full text available.
|
|Fixed in upstream.  Either use an updated glibc in the next debian
|release (I know there's no way you're going to suddenly shift STABLE to
|PaX/pie/ssp, and I'm even going to recommend AGAINST that due to
|Debian's development model), or backport the changes to whatever glibc
|you use.
|
|
| The plan is to backport changes; I was hoping to make the next (debian)
| glibc release, but no one else seems interested in fixing the bug, and
| I'm lacking free time right now.
|
Check to see if someone else did it.  I know it works on Gentoo, for a
few months now; but I don't know if it's just a newer version of glibc
or if there was also a backport for some of the older versions.  I'm
using 2.3.4 pre-relases of glibc, so obviously I'm on a fixed version,
not an old one with a backported patch.
Never do work you don't have to do; gpl code can be freely yanked back
and forth.  :)
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBV27hDd4aOud5P8RAlGSAKCQePuNYj3EsEPMwGKi9O2WpaxbdwCfSlOF
4WuNZtKqaIkRVrO/xRNZewE=
=9fzL
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian (Recap 1)

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'll do a recapitulation of what has been covered thusfar in this
message.  It's a long one, but it'll get us all on the same channel.
John Richard Moser wrote:
| I'm interested in discussing the viability of PaX on Debian.  I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
| A PaX protected base system would be best compiled ET_DYN, which can be
| done by using modified spec files or a specially patched gcc to make
| pies-by-default binaries.  Certain things don't compile this way; and
| thus would need this functionality disabled (modified spec, -fno-pic
| -nopie).  This will be discussed in greater detail later.
|
Paragraph (2) was not discussed.  Coverage of manipulating the gcc specs
file and ET_DYN adavtages and disadvantages should be discussed at some
point.  This was touched on briefly for clarification in:
http://lists.debian.org/debian-security/2004/07/msg00177.html
But did not pan out.
| A PaX protected base would also benefit from Stack Smash Protection,
| which can be done via the gcc patch ProPolice.  This imposes minimal
| overhead, which will be discussed in greater detail later.  It overlaps
| and extends many of the protections PaX offers, but catches earlier on;
| and is thus a good system to pair with PaX.
|
Paragraph (3) was touched on.  The overhead of SSP has not been
discussed; but discussion of SSP in general has.  See the end of this
post for details.
As for overhead, I'll put out that ProPolice/SSP is similar in
implementation to Immunix' StackGuard.  StackGuard, to my understanding,
places the canaries in a slightly different place; but otherwise is the
same deal.  It should thus have identical or near-identical results in a
benchmark.
Immunix did a benchmark, actually:
http://immunix.org/StackGuard/performance.html
PIE (Position Independent Executable) is said by some to have some kind
of performance hit on x86.  I've never noticed it.  It's not exactly
essential for PaX, but it is *HIGHLY* recommended, as it will reduce
potential false alarms (which entail PaX randomly killing things for no
real reason) and remove the overhead incurred by having ET_EXEC (which
need to be mapped at a constant base) executables mapped in a random
base (conflicts with previous statement, thus the overhead).
| PaX is a kernel level patch, so certain kernel settings would be needed.
| ~  Some of the settings available in PaX are high-overhead or break
| things in a way which cannot be worked around, and should thus be off.
| These will be discussed later.
|
Paragraph (4) was not discussed in great detail; kernel settings still
need to be looked over.  I am prepared to deliver and discuss these when
needed.
| The costs in terms of overhead of PaX (on legacy x86 systems where it
| must emulate an NX bit) and ProPolice are both very minimal.  With
| PAGEEXEC on hardware NX supported systems such as AMD64, there is no
| measurable overhead from PaX.  ProPolice brings no significant overhead;
| measurements taken for StackGuard (a similar system which puts the
| canaries in a different place, but is otherwise identical) are available
| for this.  This will be discussed in detail later.
|
Paragraph (5) has been covered.  The cost in terms of overhead was
discussed in:
http://lists.debian.org/debian-security/2004/07/msg00174.html
It was found with weak confidence (i.e. the tests were not exhaustive,
100% reliable distributed benchmarks; but were reasonable) that SEGMEXEC
would pose 1% performance overhead on x86-based CPUs.  SEGMEXEC does
noticably cut the address space in half.
PAGEEXEC is capable of supplying some ambiguous minimal overhead; but
it is possible for the speed-up that allows for this to be compromised,
which falls back to a variable overhead model to prevent a loss of
security, leaving us only able to say that PAGEEXEC is unpredictable.
On HW NX supporting systems (such as AMD64 or PPC), overhead is 0 from
PAGEEXEC.  The more general overhead from PaX (i.e. the extra kernel
code) is just a few extra checks and some randomization, and thus is not
at the moment predicted to be significant; at worst it is
computationally impossible for it to be greater than the total overhead
incurred from SEGMEXEC.
It is important to note that the benching tests were done with full PaX
vs PaXless.  See the message referenced above for an outline of the test
performed.
| The costs in terms of compatibility with PaX and ProPolice are also
| minimal, and mutable.  PaX breaks a handful of packages; but all of
| these can easily be marked via the chpax and/or paxctl tools to disable
| the protections that break them.  ProPolice is set off by some programs
| (firefox for one), which simply must be compiled without ProPolice
| (-fno-stack-protector -fno-stack-protector-all).
|
Paragraph (6) was covered partially

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

GOTO Masanori wrote:
| At Mon, 26 Jul 2004 15:38:37 -0400,
| John Richard Moser wrote:
|
[...]
|
|
| Is this VSYSCALL issue?  I guess we can backport it without large
| obstacle, but I have no spare time within a few days to work this bug
| because there're a lot of other remained stuff.  But I also think it's
| good idea to fix this bug before releasing sarge.
|
Yeah, that would be it.
| Regards,
| -- gotom
|
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBbAohDd4aOud5P8RAhy0AKCI1TVYqlLkVizmLZgrbRBFvcT3rACggSEQ
S8Ww3wTtEBItkzEoWihXsR8=
=/jEe
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm interested in discussing the viability of PaX on Debian.  I'd like
to discuss the changes to the base system that would be made, the costs
in terms of overhead and compatibility, the gains in terms of security,
and the mutability (elimination) of the costs.
A PaX protected base system would be best compiled ET_DYN, which can be
done by using modified spec files or a specially patched gcc to make
pies-by-default binaries.  Certain things don't compile this way; and
thus would need this functionality disabled (modified spec, -fno-pic
- -nopie).  This will be discussed in greater detail later.
A PaX protected base would also benefit from Stack Smash Protection,
which can be done via the gcc patch ProPolice.  This imposes minimal
overhead, which will be discussed in greater detail later.  It overlaps
and extends many of the protections PaX offers, but catches earlier on;
and is thus a good system to pair with PaX.
PaX is a kernel level patch, so certain kernel settings would be needed.
~  Some of the settings available in PaX are high-overhead or break
things in a way which cannot be worked around, and should thus be off.
These will be discussed later.
The costs in terms of overhead of PaX (on legacy x86 systems where it
must emulate an NX bit) and ProPolice are both very minimal.  With
PAGEEXEC on hardware NX supported systems such as AMD64, there is no
measurable overhead from PaX.  ProPolice brings no significant overhead;
measurements taken for StackGuard (a similar system which puts the
canaries in a different place, but is otherwise identical) are available
for this.  This will be discussed in detail later.
The costs in terms of compatibility with PaX and ProPolice are also
minimal, and mutable.  PaX breaks a handful of packages; but all of
these can easily be marked via the chpax and/or paxctl tools to disable
the protections that break them.  ProPolice is set off by some programs
(firefox for one), which simply must be compiled without ProPolice
(-fno-stack-protector -fno-stack-protector-all).
Neither of these systems delivers a cost in terms of complexity of use
to the user; these are both 100% transparent to the user.  Added
complexity in the form of configuring the PaX kernel; setting up the
binary markings for packages that break; and disabling the gcc
modifications for things that break are taken up by the distribution.
Both of these systems bring a significant security gain.  ProPolice
prevents buffer overflow attacks, turning them into program crashes (DoS
attacks).  Some buffer overflows, especially for buffers in structures
adjacent to function pointers or other pointers, can escape the
ProPolice logic, however; thus PaX is also needed.  This will be
explained in greater detail later.
A wikipedia article exists on PAX at http://en.wikipedia.org/wiki/PaX
and makes a good read for this.  Likewise, one for Stack Smash
Protection at http://en.wikipedia.org/wiki/ProPolice would be ideal to
look over.
Please reply and cite specific concepts you would like to discuss
further.  I would rather not write up a 10 page paper by explaining all
of these at once; but if demanded, I'll do just that.  Be ready to
swallow a large pill though.
- --John
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA+Z4hDd4aOud5P8RAqTjAJ45bMPCCW04EeDjX+NZP9m3UmC3rgCfSzt2
78Qydi7ZCMdO6vdRXuH/ZMw=
=2QiO
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Kemp wrote:
| On Sun, Jul 25, 2004 at 12:57:29PM -0400, John Richard Moser wrote:
|
|
|A PaX protected base would also benefit from Stack Smash Protection,
|which can be done via the gcc patch ProPolice.
|
|
|   I have been flirting with SSP for months now, but the most recent
|  patches included with GCC do not apply cleanly.  Watch for a bug
|  against GCC shortly with updated SSP patches.
|
Yeah I think on 3.3.4 on Gentoo has SSP
|
| This imposes minimal overhead, which will be discussed in
|greater detail later.  It overlaps and extends many of the protections
|PaX offers, but catches earlier on; and is thus a good system to pair
|with PaX.
|
|
|   I've not looked at the combination, but there is already a patched
|  binutils for PaX available unofficially for unstable, and I have
|  gcc patched with SSP (lags behind unstable releases - currently
|  a little out of date due to the breakages recently).
|
The binutils adds the header field needed for the PaX flags for paxctl.
~ This is important, because chpax uses an unused area in the header,
which is depricated.  Also, tools like strip will zero the chpax flags,
making them extremely volitile.
|
|   http://people.debian.org/~skx/ssp.html
|
|
|PaX is a kernel level patch, so certain kernel settings would be needed.
|~  Some of the settings available in PaX are high-overhead or break
|things in a way which cannot be worked around, and should thus be off.
|These will be discussed later.
|
|
|   SSP is remarkably simple to apply and works with all packages I've
|  been able to test on x86.
|
Firefox sets off SSP itself on load.
|
|The costs in terms of compatibility with PaX and ProPolice are also
|
|
|   Probably less confusing to all if you refer to ProPolice by
|  its new name, SSP, exclusively.
|
Stack Smash Protection is the new name of ProPolice?  o_o  Thought
that was the name of the concept.
|
|the protections that break them.  ProPolice is set off by some programs
|(firefox for one), which simply must be compiled without ProPolice
|(-fno-stack-protector -fno-stack-protector-all).
|
|
|   I've not noticed this - Mozilla certainly seems fine with SSP
|  compilers.  I've been using it on my own unstable boxes for some
|  time.  What, specifically, breaks?
|
Not sure.  I'm going by what I've been told by the Gentoo devs; I'm a
Hardened Gentoo user.
|
|Both of these systems bring a significant security gain.  ProPolice
|prevents buffer overflow attacks, turning them into program crashes (DoS
|attacks).  Some buffer overflows, especially for buffers in structures
|adjacent to function pointers or other pointers, can escape the
|ProPolice logic, however; thus PaX is also needed.  This will be
|explained in greater detail later.
|
|
|   I've keep a running log of all the security holes I've discovered,
| and more recently those by other members and a note as to whether
|  SSP protects against them.
|
|   This is available here:
|
|   http://shellcode.org/Advisories/
|
cool.
|   As you can see many, but not all, attacks are protected against
|  with SSP.  SELinux would almost certainly do better ...  (Because
|  the things that aren't protected against are failure to drop
|  privileges when using popen/system - SELinux could protect against
|  this, SSP cannot).
|
SELinux and SSP do two different things.  SSP prevents the program from
being exploited; SELinux contains the exploit.
PaX also aims to prevent the program from being exploited.
|
|Please reply and cite specific concepts you would like to discuss
|further.  I would rather not write up a 10 page paper by explaining all
|of these at once; but if demanded, I'll do just that.  Be ready to
|swallow a large pill though.
|
|
|   Looking forward to it already!
|
| Steve
| --
| # The Debian Security Audit Project.
| http://www.debian.org/security/audit
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBA/tFhDd4aOud5P8RAibQAJ9ybg/PKG6OslYh4EbFKBRVP/N+zQCeOu8E
TYorBgIvKO35LMneplcdjbs=
=BbdL
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX security and kernel-patch-grsecurity2 and trustees

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hanasaki wrote:
| what is the relationship between PaX, grsecurity and trustees?
|
PaX is a separate project from grsecurity.  The grsecurity developer
finds interest in PaX, and so supplies it with grsecurity.
Dunno about trustees.
| Will the kernel-patch-grsecurity2 work against 2.6.x from kernel.org
| built with kernel-package?
|
|
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBB1ihDd4aOud5P8RArMGAJ9kRn+lhFgfZZuEBjmt/HZLz8OmjACeN7nt
oIew1RsrdJS5oR/o03fNFv8=
=tgfv
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Kemp wrote:
| On Sun, Jul 25, 2004 at 02:26:15PM -0400, John Richard Moser wrote:
|
|
||   I have been flirting with SSP for months now, but the most recent
||  patches included with GCC do not apply cleanly.  Watch for a bug
||  against GCC shortly with updated SSP patches.
||
|
|Yeah I think on 3.3.4 on Gentoo has SSP
|
|
|   It does.
|
|
|The binutils adds the header field needed for the PaX flags for paxctl.
|~ This is important, because chpax uses an unused area in the header,
|which is depricated.  Also, tools like strip will zero the chpax flags,
|making them extremely volitile.
|
|
|   Shouldn't strip be updated to ignore this 'unused' field, or
|  would it be more sensible to set aside a real area for the flag?
Read again
The binutils adds the header field needed for the PaX flags for paxctl
|  ELF
|  is simple to update with new sections and maybe adding support for
|  the runtime loader/linker would be more future proof..
|
|
||   SSP is remarkably simple to apply and works with all packages I've
||  been able to test on x86.
||
|
|Firefox sets off SSP itself on load.
|
|
|   When you say 'sets of' do you mean disable?  I find that unlikely,
|  as it's not the kind of thing that can be disabled when all the
|  canary checking code is incorporated into the binary...
|
I mean firefox DIES due to a segfault.  SSP segfaults when it detects an
overflow.
If you know something we don't, I think the Hardened Gentoo team would
like to know
|
|Stack Smash Protection is the new name of ProPolice?  o_o  Thought
|that was the name of the concept.
|
|
|   SSP is the name for one implementation of stack smashing protection
|  which was previously known as ProPolice.
|   It's available from IBM at the following URL:
|
|   http://www.trl.ibm.com/projects/security/ssp/
|
:)
|
||   I've not noticed this - Mozilla certainly seems fine with SSP
||  compilers.  I've been using it on my own unstable boxes for some
||  time.  What, specifically, breaks?
||
|
|Not sure.  I'm going by what I've been told by the Gentoo devs; I'm a
|Hardened Gentoo user.
|
|
|   But interested in Debian?
|
I'm interested in getting transparent (i.e. no extra passwords, no extra
user configuration, no extra user hassle) security enhancements like PaX
and SSP into the base distributions of regular Linux distros, as I
believe they are appropriate for machines not operating in a secure
environment.  I've went at Mandrake and SuSE too, but they ignore me.
Machines in a secure environment will be interested in Adamantix or full
Hardened Gentoo, or whatever Red Hat Enterprise Server or whatever it's
called that has 1 security features comes out.  This is because they
will host sensitive data, and probably be faced with more direct attacks.
Machines *NOT* in a secure environment, however, will benefit from the
simpler, transparent subset of features that a secure system provides.
They won't be up for containing a security breach; but they'll be safely
protected from any weird Sasser or MSBlast type worms and other annoyances.
As it stands now, every little security hole in MS RPC or other system
services on Windows needs a patch to fix it.  Before these patches come
out, millions of machines get infected with worms that use the security
holes to get into the machines.
Linux is not immune; if we had 98% of the market share, every little
hole in everything would result in millions of desktop users getting
flooded with these things too.  There's no harm in BLOCKING THIS CRAP
from ever happening.  It's not going to bug the users with 5000 extra
passwords, it's not going to require a USB stick with an RSA key on it
to boot, and it's not going to eat up 50% of your CPU's processing power.
Furthermore, using these systems NOW will bring them further into the
field, exposing more attacks that get around them.  There is no security
in obscurity; we're simply faced with what we can and can't stop, and
from this we fix things so we CAN stop them, or we tell everyone when
there's a SEVERE security issue that we can't deflect.
|
|SELinux and SSP do two different things.  SSP prevents the program from
|being exploited; SELinux contains the exploit.
|
|
|   That's a simplistic explaination .. but it's not too far from
|  the truth ;)
|
Hey.  Simple is good.
|
|PaX also aims to prevent the program from being exploited.
|
|
|   The randomization is an interesting technique and it seems
|  sufficiently simple concept that it would be interesting to
|  see how well it works.
|
Did you read the wikipedia article and the docs?  :P
The restriction of mprotect() is also an interesting technique, as it
lets you force programs to listen to you.  In fact, I've had issues with
things like Flash and Java plug-ins demanding an executable stack, and
I've simply used execstack -c to turn that off.  PaX can emulate
trampolines, which is why the executable stack is needed in the first
place; and these libraries DON'T

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Steve Kemp wrote:
[...]
|Firefox sets off SSP itself on load.
|
|
|   When you say 'sets of' do you mean disable?  I find that unlikely,
|  as it's not the kind of thing that can be disabled when all the
|  canary checking code is incorporated into the binary...
|
|
http://bugs.gentoo.org/show_bug.cgi?id=45671
Ok so not on load, more like on competant use.
|Stack Smash Protection is the new name of ProPolice?  o_o  Thought
|that was the name of the concept.
|
|
|   SSP is the name for one implementation of stack smashing protection
|  which was previously known as ProPolice.
|   It's available from IBM at the following URL:
|
|   http://www.trl.ibm.com/projects/security/ssp/
|
|
[...]
|
| Steve
| --
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBDlRhDd4aOud5P8RAtNhAJ9aXKEKyl0w8oNk64NKXQTVJ54VawCfdCQV
YLGFa1P8V2hn0F8wClDmkS0=
=KIyO
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
. . . .thunderbird is being weird.  It's giving me  where  should be,
and  wehre  should be.  EH.
Andres Salomon wrote:
| On Sun, 25 Jul 2004 12:57:29 -0400, John Richard Moser wrote:
|
|
| I'm interested in discussing the viability of PaX on Debian.  I'd like
| to discuss the changes to the base system that would be made, the costs
| in terms of overhead and compatibility, the gains in terms of security,
| and the mutability (elimination) of the costs.
|
|
|
|
| I think debian-kernel would be a better place to discuss this (at least,
| the PAX stuff). I have used PAX/grsec for a while now, on 2.4, and have
| been very pleased with it.  I would love to be able to include it in
| debian 2.6 kernels, but we need to make sure that:
|
| a) it's stable (currently, we have a glibc bug that breaks PAX; #245563.
| I've also heard reports of various grsec problems on 2.6; I don't
know how
| many of those are PAX issues)
PaX is stable, grsecurity I can't comment on.
I'm only suggesting PaX.  PaX is interestingly enough hosted by
grsecurity; PaX' previous hosting cost money.
http://pax.grsecurity.net/
| b) it doesn't introduce significant overhead (we need *real*, up-to-date
| benchmarks here); i'm told that there have been optimizations to PAGEEXEC
| that make it comparable in speed to SEGMEXEC, but I haven't tried it.
Anything that gives you an executable area existing above data will lose
the PAGEEXEC speedup.  This speedup is the same kind of thing Exec
Shield does; except that when data exists in the code segment, it falls
back to old PAGEEXEC rather than becoming executable like Exec Shield does.
On 64 bit (amd64 for example) and other Hardware NX supporting
processors, there will be *no* overhead imposed by PAGEEXEC.  :)
| c) it doesn't introduce limitations (SEGMEXEC isn't an option, for
| example, since it splits the process address space in half, and can't be
| turned off to reclaim address space) that aren't easily disabled.
I can give a patch that will allow pax_defaultnx={segm|page}exec on the
kernel command line.
Also, paxctl/chpax can mark binaries to disable segmexec/pageexec.
|
|
|
| A PaX protected base system would be best compiled
|
| ET_DYN, which can be
|
| done by using modified spec files or a specially patched gcc to make
| pies-by-default binaries.  Certain things don't compile this way; and
| thus would need this functionality disabled (modified spec, -fno-pic -
| -nopie).  This will be discussed in greater detail later.
|
| A PaX protected base would also benefit from Stack Smash Protection,
| which can be done via the gcc patch ProPolice.  This imposes minimal
| overhead, which will be discussed in greater detail later.  It overlaps
| and extends many of the protections PaX offers, but catches earlier on;
| and is thus a good system to pair with PaX.
|
|
|
| I haven't tried SSP yet, but I've heard good things about it.  I'll have
| to do research on it when I have more free time.
|
:)  http://en.wikipedia.org/wiki/Stack_smash_protection (same as the
ProPolice article, which is a redirect) shows how this works.
|
|
| PaX is a kernel level
|
| patch, so certain kernel settings would be needed.
|
| ~  Some of the settings available in PaX are high-overhead or break
| things in a way which cannot be worked around, and should thus be off.
| These will be discussed later.
|
|
|
| Yes.  We cannot have major regressions in the kernel, with the
| introduction of something like this.
|
|
There will be breakage in places; but I can point out the settings that
cause permenant breakage.  All of the other breakage will be solvable
simply by using paxctl/chpax to mark the affected binaries.  These can
be distributed marked up properly in their .deb packages.
|
| The costs in terms of overhead of PaX (on legacy x86 systems where it
| must emulate an NX bit) and ProPolice are both very minimal.  With
| PAGEEXEC on hardware NX supported systems such as AMD64, there is no
| measurable overhead from PaX.  ProPolice brings no significant overhead;
| measurements taken for StackGuard (a similar system which puts the
| canaries in a different place, but is otherwise identical) are available
| for this.  This will be discussed in detail later.
|
|
|
| Do you have any real benchmarks showing exactly how much overheard is
| added on common hardware (i386, powerpc, and amd64)?  I'm merely
| interested in 2.6.
|
No real benchmarks.  I did a SEGMEXEC test on 2.6 that showed a scalar
0.6% overhead from full PaX (aslr and SEGMEXEC emulation), by compiling
the same kernel twice:
1.  Compile a kernel, install it
2.  Patch the source tree with PaX, and repete 1
3.  `make clean` in the original source tree
4.  `make menuconfig` in the original source tree to regenerate
dependency data
5.  Reboot into the non-PaX kernel
6.  `time -p make all` in the source tree (makes bzImage and modules)
7.  Repete steps 3 through 6 with the PaX kernel
8.  Divide the time gathered in the PaX

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russell Coker wrote:
| On Mon, 26 Jul 2004 02:57, John Richard Moser [EMAIL PROTECTED]
wrote:
|
|I'm interested in discussing the viability of PaX on Debian.  I'd like
|to discuss the changes to the base system that would be made, the costs
|in terms of overhead and compatibility, the gains in terms of security,
|and the mutability (elimination) of the costs.
|
|
| Before we can even start thinking about PaX on Debian we need to find a
| maintainer for the kernel patch who will package new versions of the
patch
| which apply to the Debian kernel source tree.  We have had a few
flame-wars
| about this in the past which have had no positive result because
no-one has
| volunteered to do the kernel coding work.
|
|
Are you talking PaX or grsecurity?  PaX is significantly less invasive
than grsecurity.  There will still be issues, of course.
Where would I see debian's 2.6.7 source tree?  I'm not a deb user,
remember, so I'll need a tarball or something.
|A PaX protected base system would be best compiled ET_DYN, which can be
|done by using modified spec files or a specially patched gcc to make
|pies-by-default binaries.  Certain things don't compile this way; and
|thus would need this functionality disabled (modified spec, -fno-pic
|-nopie).  This will be discussed in greater detail later.
|
|
| Debian does not use spec files, spec files are for RPM based
distributions.
| It would have to be a modification to debian/rules in all the
packages, or a
| modification to gcc and/or dpkg-buildpackage.
|
No, gcc spec files, that tell gcc how to behave.  This was used on
gentoo to mess with gcc's default behavior for a while.
try the command:
gcc -dumpspecs
Also try looking at:
/usr/lib/gcc-lib/Target/version/specs
You'd need to fudge that file I believe to alter gcc's default behavior.
~ This was done by the Hardened Gentoo project, but was dropped in favor
of a gcc patch.  Either way, it's been done before.
|
|A PaX protected base would also benefit from Stack Smash Protection,
|which can be done via the gcc patch ProPolice.  This imposes minimal
|overhead, which will be discussed in greater detail later.  It overlaps
|and extends many of the protections PaX offers, but catches earlier on;
|and is thus a good system to pair with PaX.
|
|
| We have recently discussed this on at least one of the lists you
posted to.
| The end result of the discussion is that GCC is getting another SSP type
| technology known as mudflap.  Mudflap depends on some major new
features of
| GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
| Debian GCC people don't want to merge in other patches which have no
apparent
| chance of being included upstream.
|
Then don't use ProPolice/SSP for now.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBH75hDd4aOud5P8RAvATAJ4p+Kfut/en14Dwenv7UDez86O2KgCeIJcG
kP7jnKii7eDGHwiO39MpJjI=
=P617
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russell Coker wrote:
| On Mon, 26 Jul 2004 13:48, John Richard Moser [EMAIL PROTECTED]
wrote:
|
|| Before we can even start thinking about PaX on Debian we need to find a
|| maintainer for the kernel patch who will package new versions of the
|| patch which apply to the Debian kernel source tree.  We have had a few
|
|Are you talking PaX or grsecurity?  PaX is significantly less invasive
|than grsecurity.  There will still be issues, of course.
|
|
| PaX.  AFAIK the only PaX kernel-patch package in Debian is the Adamantix
| kernel source, which has RSBAC and a bunch of other stuff, and the GRSec
| patch.  Neither of them apply to the Debian kernel source tree.
|
|
I'm pretty much proposing that all your sources include PaX; your
binaries can have it compiled out.  I've got a working PaX patch for
2.6.7-ck* :)  It was only a 1 miss issue.  I'll see if Deb sources are
kind or if they rape my ass. . .
|Where would I see debian's 2.6.7 source tree?  I'm not a deb user,
|remember, so I'll need a tarball or something.
|
|
| http://ftp.debian.org/debian/pool/main/k/
|
OK how the hell does this work?  What's this supposed to apply to?
kernel-source-2.6.7_2.6.7-3_all.deb ?
ahh, 2.6.7 +  kernel-source-2.6.7_2.6.7-3.diff.gz
I'll get on this right away. . . . I don't really see anything that
stands out in my brain, so I think PaX will apply pretty cleanly to this.

icebox linux-2.6.7-deb # patch -p1  ../kernel-source-2.6.7_2.6.7-3.diff
patching file debian/changelog
patching file debian/control
patching file debian/apply
patching file debian/patches/drivers-sb-pnp_unregister.dpatch
patching file debian/patches/fs-cramfs-constify.dpatch
patching file debian/patches/fs-jfs-compile.dpatch
patching file debian/patches/netlink-macro-fixups.dpatch
patching file debian/patches/acpi-typo.dpatch
patching file debian/patches/envp.dpatch
patching file debian/patches/include-linux-mca.h-fixups.dpatch
patching file debian/patches/x86-i486_emu.dpatch
patching file debian/patches/doc-post_halloween.dpatch
patching file debian/patches/fs-isofs-acorn.dpatch
patching file debian/patches/drivers-scsi-advansys-dma_api.dpatch
patching file debian/patches/modular-ide-pnp.dpatch
patching file debian/patches/include-missing-includes.dpatch
patching file debian/patches/include-thread_info-ifdefs.dpatch
patching file debian/patches/modular-ide.dpatch
patching file debian/patches/fs-isofs-dont-check-period.dpatch
patching file
debian/patches/dont-dereference-netdev.name-before-register_netdev.dpatch
patching file debian/patches/drivers-net-tg3-readd.dpatch
patching file debian/patches/DPATCH
patching file debian/patches/drivers-usb-net-pegasus-startstop_queue.dpatch
patching file debian/patches/drivers-net-via_rhine-avoid_bitfield.dpatch
patching file debian/patches/remove-references-to-removed-drivers.dpatch
patching file debian/patches/drivers-ide-dma-blacklist-toshiba.dpatch
patching file debian/patches/alpha-epoch-comment.dpatch
patching file debian/patches/ipsec-missing_wakeup.dpatch
patching file debian/patches/00list-1
patching file debian/patches/drivers-scsi-generic_proc_info.dpatch
patching file debian/patches/drivers-isdn-io_funcs-fixup.dpatch
patching file debian/patches/drivers-scsi-sd-NO_SENSE.dpatch
patching file debian/patches/extraversion.dpatch
patching file debian/patches/alpha-tembits.dpatch
patching file debian/patches/drivers-input-psaux-hacks.dpatch
patching file debian/patches/drivers-input-hiddev-HIDIOCGUCODE.dpatch
patching file debian/patches/drivers-atkbd-quiten.dpatch
patching file debian/patches/drivers-scsi_changer.dpatch
patching file debian/patches/modular-swsusp.dpatch
patching file debian/patches/drivers-dpt_i2o-fixup.dpatch
patching file debian/patches/drivers-net-8139too-locking.dpatch
patching file debian/patches/drivers-net-irda-dma_api.dpatch
patching file debian/patches/modular-vesafb.dpatch
patching file debian/patches/chown-gid-check.dpatch
patching file debian/patches/drivers-ftape.dpatch
patching file debian/patches/fs-asfs.dpatch
patching file debian/patches/00list-2
patching file debian/patches/fs-asfs-2.dpatch
patching file debian/patches/00list-3
patching file debian/patches/chown-procfs.dpatch
patching file debian/patches/3w-9xxx.dpatch
patching file debian/patches/marvell-pegasos.dpatch
patching file debian/patches/xfs-update.dpatch
patching file debian/patches/marvell-mm.dpatch
patching file debian/patches/netfilter-signedcharbug.dpatch
patching file debian/README.NMU
patching file debian/rules
patching file debian/make-kernel-patch-pkgs
patching file debian/ChangeLog-2.6.7
patching file debian/substvars
patching file debian/prune-non-free
patching file debian/list-patches
patching file debian/unpatch
patching file debian/make-substvars
patching file debian/copyright
patching file debian/substvars.safe
patching file debian/official
patching file debian/README.Debian

So far so good, PaX next, dry run test real quick.
icebox linux-2.6.7-deb

Re: PaX on Debian

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Found a problem.
Russell Coker wrote:
| On Mon, 26 Jul 2004 02:57, John Richard Moser [EMAIL PROTECTED]
wrote:
[...]
|
| We have recently discussed this on at least one of the lists you
posted to.
| The end result of the discussion is that GCC is getting another SSP type
| technology known as mudflap.  Mudflap depends on some major new
features of
| GCC 3.5, so it looks like we won't be getting this until GCC 3.5 as the
| Debian GCC people don't want to merge in other patches which have no
apparent
| chance of being included upstream.
|
- cut
| Upstream has already decided to support mudflap in GCC 3.5, which is
| even more far-reaching than SSP.
I'm not sure whether all users of SSP would he happy with mudflap as a
replacement. It has a different focus; it was designed as debugging
tool. For example it probably incurs a much larger performance
overhead, since basically every pointer dereference goes through a
hash table.
- cut
http://lists.debian.org/debian-devel/2004/07/msg01154.html
It's a high-overhead debugging tool?  I can understand this:  The GCC
team would be more concerned with helping you FIX security issues than
blocking them at exploit time.  It shouldn't interfere with ProPolice
anyway, I've been told, so you may want to go with SSP/ProPolice for
security reasons.  Either way, moving to mudflap is going to require a
full system recompile on your end, so what do you really lose?  :)
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitely stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBBIvNhDd4aOud5P8RAlZKAKCIQ1bhrB6NkQMl36TBBXMD8ypyjwCfVhC8
+HS4a3waTxdgclEdfsmGPqc=
=la0p
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Advice needed, trying to find the vulnerable code on Debian webserver.

[Richard Atterer]

You could also try installing snoopy, which logs all commands executed by 
users to auth.log. Then look for unusual commands executed by user 
www-data if you suspect insecure PHP scripts etc.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Advice needed, trying to find the vulnerable code on Debian webserver.

[Richard Atterer]

You could also try installing snoopy, which logs all commands executed by 
users to auth.log. Then look for unusual commands executed by user 
www-data if you suspect insecure PHP scripts etc.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Spam fights

[Richard Atterer]

On Thu, Jun 10, 2004 at 12:27:04PM +0300, Dmitry Golubev wrote:
 I second that. If I receive a confirmation message I never respond to it! 

If *I* receive a confirmation message, I always respond to it!

That's because all confirmation messages I get are in response to spam with
my address in the From field. If I confirm, the person sending me the
confirmation message will be delivered the spam. If more people did this, 
confirmation senders would notice that the system doesn't work.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Spam fights

[Richard Atterer]

On Thu, Jun 10, 2004 at 12:27:04PM +0300, Dmitry Golubev wrote:
 I second that. If I receive a confirmation message I never respond to it! 

If *I* receive a confirmation message, I always respond to it!

That's because all confirmation messages I get are in response to spam with
my address in the From field. If I confirm, the person sending me the
confirmation message will be delivered the spam. If more people did this, 
confirmation senders would notice that the system doesn't work.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Non-existent user able to log in??? hacked????

[Richard Atterer]

Hi Arnaud,

just some points - I have no idea whether you've been hacked.

On Tue, May 18, 2004 at 10:21:22PM +0200, A. Loonstra wrote:
 Last night I found the following in my wtmp:

 test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
 
 I had this test account once but removed account rightaway. So this
 shouldn't show up in my logs anyhow.

Are you sure there's nothing left over from that account? I know little
about wu-ftpd configuration - maybe some .db files need refreshing from the
respective user/password files, or similar?

 The weird thing is that syslog
 shows something else:

 May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
 May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in
 /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous

Looks a bit like the host tried a couple of very common login names. The IP
is owned by skidmore.edu, so this could be some dorm room hacker...

Regardless of whether that person was successful in getting on your
machine, it might be a good idea to contact the skidmore.edu admins
http://www2.skidmore.edu/cits/staffdir/staff_dir.cfm. They might be able
to tell who was logged into the machine at the time, or has been assigned
that IP. They most probably won't tell you who, but might educate the 
person in question about the fact that what they do is unlawful.

(Dunno about America, but in Germany, the act of Daten ausspähen is a
crime - roughly paraphrased, this means accessing files which are protected
from being viewed by anyone. So trying to log in is the attempt of a crime,
which is also a crime. IANAL though.)

 I have nothing in /etc/passwd, /etc/shadow or anywhere else...
 a grep test on passwd* or shadow* reveals nothing. So how is it possible 
 that this test user is able to login.

I think the first thing you should do is to check whether the binaries for
your ftpd, PAM modules, inetd, tcp wrappers and all the related stuff have
been modified. The correct, paranoid way to do this is to boot into, say,
Knoppix, from CD, download known good packages, and compare the md5sums.

It doesn't look like the attacker did anything once he was logged in (maybe
he was just scanning the net for open FTP servers), but if any doubt
remains, reinstall from scratch.

Maybe also consider using a different ftpd...

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Secure temporary fifo creation

[Richard Atterer]

On Mon, May 17, 2004 at 07:45:17PM -0500, Greg Deitrick wrote:
 What is the recommended method for securely creating a temporary named pipe 
 in 
 C code?

See this for an interesting discussion:
http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html

You can e.g. adapt the code from the GNOME guidelines mentioned there, and 
just create your fifo instead of doing the open().

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Non-existent user able to log in??? hacked????

[Richard Atterer]

Hi Arnaud,

just some points - I have no idea whether you've been hacked.

On Tue, May 18, 2004 at 10:21:22PM +0200, A. Loonstra wrote:
 Last night I found the following in my wtmp:

 test ftpd19097141.222.42.5 Sat May 15 10:57 - 10:57  (00:00)
 
 I had this test account once but removed account rightaway. So this
 shouldn't show up in my logs anyhow.

Are you sure there's nothing left over from that account? I know little
about wu-ftpd configuration - maybe some .db files need refreshing from the
respective user/password files, or similar?

 The weird thing is that syslog
 shows something else:

 May 15 10:57:41 matilda wu-ftpd[19097]: connect from 141.222.42.5
 May 15 10:57:44 matilda wu-ftpd[19097]: FTP LOGIN REFUSED (ftp not in
 /etc/passwd) FROM 141.222.42.5 [141.222.42.5], anonymous

Looks a bit like the host tried a couple of very common login names. The IP
is owned by skidmore.edu, so this could be some dorm room hacker...

Regardless of whether that person was successful in getting on your
machine, it might be a good idea to contact the skidmore.edu admins
http://www2.skidmore.edu/cits/staffdir/staff_dir.cfm. They might be able
to tell who was logged into the machine at the time, or has been assigned
that IP. They most probably won't tell you who, but might educate the 
person in question about the fact that what they do is unlawful.

(Dunno about America, but in Germany, the act of Daten ausspähen is a
crime - roughly paraphrased, this means accessing files which are protected
from being viewed by anyone. So trying to log in is the attempt of a crime,
which is also a crime. IANAL though.)

 I have nothing in /etc/passwd, /etc/shadow or anywhere else...
 a grep test on passwd* or shadow* reveals nothing. So how is it possible 
 that this test user is able to login.

I think the first thing you should do is to check whether the binaries for
your ftpd, PAM modules, inetd, tcp wrappers and all the related stuff have
been modified. The correct, paranoid way to do this is to boot into, say,
Knoppix, from CD, download known good packages, and compare the md5sums.

It doesn't look like the attacker did anything once he was logged in (maybe
he was just scanning the net for open FTP servers), but if any doubt
remains, reinstall from scratch.

Maybe also consider using a different ftpd...

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: i want to hide return path...

[Richard Atterer]

On Tue, May 04, 2004 at 02:45:58PM +0200, Marcin wrote:
 Hello,
 
 I am using debian postfix. When a mail from the PHP (under apache) the mail header 
 contain:
 ---
 Return-Path: [EMAIL PROTECTED]
 ---
 
 I want to hide only this ONE user.
 It is possible ?
[...]
 The only idea is change postfix sources ? I just compiled postfix from
 sources so this is not problem if it will help.

What about changing your PHP? See
http://www.zend.com/manual/function.mail.php#AEN50127 - you can add
parameters to the mail() call in PHP and pass an -f switch to the
sendmail invocation. That way, you can specify any sender address you like.

HTH,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: i want to hide return path...

[Richard Atterer]

On Tue, May 04, 2004 at 02:45:58PM +0200, Marcin wrote:
 Hello,
 
 I am using debian postfix. When a mail from the PHP (under apache) the mail 
 header contain:
 ---
 Return-Path: [EMAIL PROTECTED]
 ---
 
 I want to hide only this ONE user.
 It is possible ?
[...]
 The only idea is change postfix sources ? I just compiled postfix from
 sources so this is not problem if it will help.

What about changing your PHP? See
http://www.zend.com/manual/function.mail.php#AEN50127 - you can add
parameters to the mail() call in PHP and pass an -f switch to the
sendmail invocation. That way, you can specify any sender address you like.

HTH,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: what process is using a port

[Richard Collins]

 Is there a way to figure out what program is using a port. For example I
 want to know which process is using port 80. How can I do this?

netstat -anp | grep 80

or for listening ports

netstat -anp | grep LIST


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

Re: what process is using a port

[Richard Collins]

 Is there a way to figure out what program is using a port. For example I
 want to know which process is using port 80. How can I do this?

netstat -anp | grep 80

or for listening ports

netstat -anp | grep LIST

Re: name based virtual host and apache-ssl

[Richard Atterer]

On Wed, Mar 24, 2004 at 12:18:58PM +0100, J.H.M. Dassen (Ray) wrote:
 Yes, see How to use TLS in application protocols under
 http://www.gnu.org/software/gnutls/documentation/gnutls/gnutls.html for
 details. 

Interesting - I didn't know this was possible! There's even support for it 
in Apache 2... but do today's browsers support it?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: name based virtual host and apache-ssl

[Richard Atterer]

On Wed, Mar 24, 2004 at 12:18:58PM +0100, J.H.M. Dassen (Ray) wrote:
 Yes, see How to use TLS in application protocols under
 http://www.gnu.org/software/gnutls/documentation/gnutls/gnutls.html for
 details. 

Interesting - I didn't know this was possible! There's even support for it 
in Apache 2... but do today's browsers support it?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

See your MS-Access or SQL-Server change in real time - $89

[richard fencel]

 
DbWatch- the data 
debugger

DBWatch displaysin blue, green and red all SqlServer or 
MsAccess records that havebeeninserted,deleted or changed by 
your application. Only $89. www.fencel.com. 
 

To unsubscribe, write to:[EMAIL PROTECTED]

Richard Fencel
40 Redberry 
Irvine, Ca 92618-3902




 

dbwatchemail.gif

See your MS-Access or SQL-Server change in real time - $89

[richard fencel]

 
DbWatch- the data 
debugger

DBWatch displaysin blue, green and red all SqlServer or 
MsAccess records that havebeeninserted,deleted or changed by 
your application. Only $89. www.fencel.com. 
 

To unsubscribe, write to:[EMAIL PROTECTED]

Richard Fencel
40 Redberry 
Irvine, Ca 92618-3902




 

Re: mozilla - the forgotten package?

[Richard Atterer]

On Tue, Mar 09, 2004 at 11:59:01AM -0800, Matt Zimmerman wrote:
 Anyone with the time and ability can work on a project like this without
 joining the security team.  Mozilla in particular is a huge amount of
 work to bring up to date and so far no one has found it critical enough
 relative to the effort required.

Is there a list of such unresolved security problems which is accessible by
people not in the security team? There was talk once about providing such a
list, but AFAICT nothing happened - hmm, or is it the list of
security-tagged bugs?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: mozilla - the forgotten package?

[Richard Atterer]

On Tue, Mar 09, 2004 at 11:59:01AM -0800, Matt Zimmerman wrote:
 Anyone with the time and ability can work on a project like this without
 joining the security team.  Mozilla in particular is a huge amount of
 work to bring up to date and so far no one has found it critical enough
 relative to the effort required.

Is there a list of such unresolved security problems which is accessible by
people not in the security team? There was talk once about providing such a
list, but AFAICT nothing happened - hmm, or is it the list of
security-tagged bugs?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Big VPN

[Richard Atterer]

On Wed, Mar 03, 2004 at 09:39:06AM +0100, Jaros?aw Tabor wrote:
 I don't know IPSec so good, so one question: if I will add new node
 (LAN), do I need to update configuration of all others about it ? This is
 my biggest concern...

I'm not so sure about this - anybody else?

But I think it's possible - with X.509 certificates, shouldn't you be able 
to

 1) Set up one root CA (certificate authority), which issues certificates 
and a revocation list
 2) Sign the individual LANs' certificates with that CA's key
 3) Tell all IPSec routers in your LANs to trust certificates with a 
signature by the root CA
 4) Now, when one LAN A connects to another B for the first time, A can
send its own signed certificate. B allows the connection to be set up 
due to the fact that A's certificate carries a signature of the CA.

This means that each of your 100 LANs only needs a copy of the root CA's 
certificate in order to connect to any other LAN.

You must maintain a CRL (certificate revocation list) to be able to remove
certain LANs from your big VPN without updating all nodes. See the PDF
which is the first link on http://www.strongsec.com/freeswan/, sections
3.1 and 3.2.

HTH,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Big VPN

[Richard Atterer]

Hi, CCing the list again because other people might have cleverer ideas. I 
hope you don't mind, Jaroslaw.

On Wed, Mar 03, 2004 at 11:36:27AM +0100, Jaros?aw Tabor wrote:
 That's OK. But what about routing ? How to inform other nodes, about new
 subnet ? I think, that this will require some kind of dynamic routing and
 IPSec on demand. But, as I see from freeswan and openswan doc, this isn't
 supported.

Hmm, you are right... The only solution I see ATM is to pre-configure an
appropriate amount of subnets on each LAN's IPSec router in advance, say
200. :-/ LAN number n gets the network 10.0.n.0/24, and its IPSec router is
set up as ipsecn.mydomain.net.

Later, when network number 42 has been set up to use 10.0.42.0/24, you only
need to update the DNS entry of ipsec42.mydomain.net and all other LANs 
should be able to use it. (New IPSec links will be set up on demand once 
anyone tries to connect to the new network.)

Obviously, an alternative would be to have one central node which acts as
as a router between any two LANs. This will be much easier to maintain, I
don't know if the resulting single point of failure and possibly lower
performance are a problem for you. Each of the 100 LANs would just route
all 10.0.0.0/16 addresses to the central node, and only the central node
would be trusted, so you don't have to mess with CAs etc...

Cheers,

  Richard

--
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Big VPN

[Richard Atterer]

On Wed, Mar 03, 2004 at 09:39:06AM +0100, Jaros?aw Tabor wrote:
 I don't know IPSec so good, so one question: if I will add new node
 (LAN), do I need to update configuration of all others about it ? This is
 my biggest concern...

I'm not so sure about this - anybody else?

But I think it's possible - with X.509 certificates, shouldn't you be able 
to

 1) Set up one root CA (certificate authority), which issues certificates 
and a revocation list
 2) Sign the individual LANs' certificates with that CA's key
 3) Tell all IPSec routers in your LANs to trust certificates with a 
signature by the root CA
 4) Now, when one LAN A connects to another B for the first time, A can
send its own signed certificate. B allows the connection to be set up 
due to the fact that A's certificate carries a signature of the CA.

This means that each of your 100 LANs only needs a copy of the root CA's 
certificate in order to connect to any other LAN.

You must maintain a CRL (certificate revocation list) to be able to remove
certain LANs from your big VPN without updating all nodes. See the PDF
which is the first link on http://www.strongsec.com/freeswan/, sections
3.1 and 3.2.

HTH,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Big VPN

[Richard Atterer]

Hi, CCing the list again because other people might have cleverer ideas. I 
hope you don't mind, Jaroslaw.

On Wed, Mar 03, 2004 at 11:36:27AM +0100, Jaros?aw Tabor wrote:
 That's OK. But what about routing ? How to inform other nodes, about new
 subnet ? I think, that this will require some kind of dynamic routing and
 IPSec on demand. But, as I see from freeswan and openswan doc, this isn't
 supported.

Hmm, you are right... The only solution I see ATM is to pre-configure an
appropriate amount of subnets on each LAN's IPSec router in advance, say
200. :-/ LAN number n gets the network 10.0.n.0/24, and its IPSec router is
set up as ipsecn.mydomain.net.

Later, when network number 42 has been set up to use 10.0.42.0/24, you only
need to update the DNS entry of ipsec42.mydomain.net and all other LANs 
should be able to use it. (New IPSec links will be set up on demand once 
anyone tries to connect to the new network.)

Obviously, an alternative would be to have one central node which acts as
as a router between any two LANs. This will be much easier to maintain, I
don't know if the resulting single point of failure and possibly lower
performance are a problem for you. Each of the 100 LANs would just route
all 10.0.0.0/16 addresses to the central node, and only the central node
would be trusted, so you don't have to mess with CAs etc...

Cheers,

  Richard

--
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Big VPN

[Richard Atterer]

On Tue, Mar 02, 2004 at 10:00:58PM +0100, I.R. van Dongen wrote:
 You might want to check tinc (http://tinc.nl.linux.org)

I strongly recommend *not* to use tinc. 
http://www.securityfocus.com/archive/1/249142 illustrates that the
authors didn't have enough expertise to build a secure tool 2 years ago.
The problems were still present last autumn, see
http://www.mit.edu:8008/bloom-picayune/crypto/14238. What a track record!

With VPN software, IPSec is the only real option if you want to be certain
it is secure.

 Jaroslaw Tabor wrote:
 I'm looking for good linux (debian of course) based solution for VPN
 connecting about 100 LANs. The solution should be stable, easy for
 implementation and easy for management. I've some expirience with VPNs
 based on PPTPd, but not so big.

PPTP is also believed not to be quite insecure, see
http://www.schneier.com/pptp-faq.html (NB old!). A small number of people
believe it's OK these days due to some improvements made by Microsoft
http://www.schneier.com/paper-pptpv2.html, but I still wouldn't recommend
it.

Does each of these 100 LANs need to connect to *any* other LAN, or just to 
your LAN? Are the LANs real LANs or do you only want to connect single 
road warrior machines to your LAN?

 I've reviewed freeswan and OE feauture. This looks nice, but I'm afraid
 about security. If I understand this solution right there is no
 authentication at all. So every one can connect to the LANs if he will
 spoof IP.

I don't think it is the right thing for you, yes. Its main objective (in my 
eyes) is to protect general internet traffic from people who are not 
willing/able to do man-in-the-middle attacks, i.e. from people who just 
sniff on the wire. At least that's what it boils down to as long as no 
secure DNS is available...

 I need something better, because I cannot trust to LAN users. To avoid
 that, I have idea, to use some kind of secure DNS, which will answer
 only to authorized peers, but I don't know how to do it.

What's wrong with IPSec with X.509 certificates? You can give out a signed
certificate to all people who should get access to your network, and remove 
individual people from the allowed list if necessary. IPSec works with 
all OSes as clients. The only downside (IMHO) is that the server can be 
fairly complex to set up for this kind of scenario.

Secure DNS doesn't exist today, does it?

 Finally, the questions:
 Did someone sucessfully build such network ? If yes, how?

Well, since I'm in the mood of handing out URLs today ;-), here are some
useful pages I found about IPSec setups involving both Linux and Windows
clients.

http://www.freeswan.org/ - you've seen this already I guess :)
http://www.natecarlson.com/linux/ipsec-x509.php
http://www.ipsec-howto.org/ - new kernel 2.6.0 IPSec
http://ipsec.math.ucla.edu/services/ipsec.html
http://lugbe.ch/action/reports/ipsec_htbe.phtml
http://vpn.ebootis.de/

 Is there any solution to easily manage keys in so big network, if I will
 choice freeswan (or other) without OE ?

100 VPN connections isn't /that/ much, I think FreeS/WAN or the 2.6.0 IPSec 
should be able to handle it. (Maybe ask the developers to ensure it does.)

 PS: Sorry, for my poor english, I'm not a native speaker.
 me neither :)
Ditto. :-)

ü,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Big VPN

[Richard Atterer]

On Tue, Mar 02, 2004 at 10:00:58PM +0100, I.R. van Dongen wrote:
 You might want to check tinc (http://tinc.nl.linux.org)

I strongly recommend *not* to use tinc. 
http://www.securityfocus.com/archive/1/249142 illustrates that the
authors didn't have enough expertise to build a secure tool 2 years ago.
The problems were still present last autumn, see
http://www.mit.edu:8008/bloom-picayune/crypto/14238. What a track record!

With VPN software, IPSec is the only real option if you want to be certain
it is secure.

 Jaroslaw Tabor wrote:
 I'm looking for good linux (debian of course) based solution for VPN
 connecting about 100 LANs. The solution should be stable, easy for
 implementation and easy for management. I've some expirience with VPNs
 based on PPTPd, but not so big.

PPTP is also believed not to be quite insecure, see
http://www.schneier.com/pptp-faq.html (NB old!). A small number of people
believe it's OK these days due to some improvements made by Microsoft
http://www.schneier.com/paper-pptpv2.html, but I still wouldn't recommend
it.

Does each of these 100 LANs need to connect to *any* other LAN, or just to 
your LAN? Are the LANs real LANs or do you only want to connect single 
road warrior machines to your LAN?

 I've reviewed freeswan and OE feauture. This looks nice, but I'm afraid
 about security. If I understand this solution right there is no
 authentication at all. So every one can connect to the LANs if he will
 spoof IP.

I don't think it is the right thing for you, yes. Its main objective (in my 
eyes) is to protect general internet traffic from people who are not 
willing/able to do man-in-the-middle attacks, i.e. from people who just 
sniff on the wire. At least that's what it boils down to as long as no 
secure DNS is available...

 I need something better, because I cannot trust to LAN users. To avoid
 that, I have idea, to use some kind of secure DNS, which will answer
 only to authorized peers, but I don't know how to do it.

What's wrong with IPSec with X.509 certificates? You can give out a signed
certificate to all people who should get access to your network, and remove 
individual people from the allowed list if necessary. IPSec works with 
all OSes as clients. The only downside (IMHO) is that the server can be 
fairly complex to set up for this kind of scenario.

Secure DNS doesn't exist today, does it?

 Finally, the questions:
 Did someone sucessfully build such network ? If yes, how?

Well, since I'm in the mood of handing out URLs today ;-), here are some
useful pages I found about IPSec setups involving both Linux and Windows
clients.

http://www.freeswan.org/ - you've seen this already I guess :)
http://www.natecarlson.com/linux/ipsec-x509.php
http://www.ipsec-howto.org/ - new kernel 2.6.0 IPSec
http://ipsec.math.ucla.edu/services/ipsec.html
http://lugbe.ch/action/reports/ipsec_htbe.phtml
http://vpn.ebootis.de/

 Is there any solution to easily manage keys in so big network, if I will
 choice freeswan (or other) without OE ?

100 VPN connections isn't /that/ much, I think FreeS/WAN or the 2.6.0 IPSec 
should be able to handle it. (Maybe ask the developers to ensure it does.)

 PS: Sorry, for my poor english, I'm not a native speaker.
 me neither :)
Ditto. :-)

ü,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Tripwire (clone) which would you prefer?

[Richard Atterer]

Also see this page for a useful comparison between AIDE and tripwire:

http://www.fbunet.de/aide.shtml

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Tripwire (clone) which would you prefer?

[Richard Atterer]

Also see this page for a useful comparison between AIDE and tripwire:

http://www.fbunet.de/aide.shtml

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Help! File permissions keep changing...

[Richard Atterer]

On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
 You can try to settle it by using umask (as other's have suggested) but 
 users can defeat that. If you _really_ want to fix it, have a cronjob do 
 this (quick and dirty, could be _really_ improved)
 
 --
 DIR_TO_FIX=/home/groupX
 GROUP=mygroup
 PERM=g+rwX
 
 find $DIR_TO_FIX -type f -o -type d | xargs chown $GROUP 
 # or chown -hR $GROUP $DIR_TO_FIX
 find $DIR_TO_FIX -type f -o -type d | xargs chmod $PERM
 # or chmod -hR $PERM $DIR_TO_FIX
 --

Waah, SCARY!

Users can create hard links to arbitrary files in that directory, e.g. 
links to other users' private files or to /etc/shadow, and automatically 
get read access to those files.

umask *is* the right solution (together with a sticky-bit dir). Set up a
default umask which allows global read access and *let* users defeat it! If
they know how to change their umask to something more restrictive, they're
bound to know what they're doing!

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: arpwatch and arp packets ...urgent

[Richard Atterer]

On Wed, Feb 18, 2004 at 11:32:00AM +0100, m wrote:
 I want to be able to set public IP's for computers in LAN. Is any
 other solution ? I dont know about it - if you so - please let me know
 :)

Have you tried explicit routing entries for the IPs in question? I'm not 
too sure if this actually works, but if eth1 is the interface on your 
router which is connected to 192.168.0.0/24 and you want to pass on packets 
for 1.2.3.4 to eth1, use this on your router:

  route add -host 1.2.3.4 dev eth0

This assumes that packets destined for 1.2.3.4 are sent to your router, and 
that one host in your LAN is configured to the address 1.2.3.4.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Help! File permissions keep changing...

[Richard Atterer]

On Wed, Feb 18, 2004 at 02:15:36AM +0100, Javier Fernández-Sanguino Peña wrote:
 You can try to settle it by using umask (as other's have suggested) but 
 users can defeat that. If you _really_ want to fix it, have a cronjob do 
 this (quick and dirty, could be _really_ improved)
 
 --
 DIR_TO_FIX=/home/groupX
 GROUP=mygroup
 PERM=g+rwX
 
 find $DIR_TO_FIX -type f -o -type d | xargs chown $GROUP 
 # or chown -hR $GROUP $DIR_TO_FIX
 find $DIR_TO_FIX -type f -o -type d | xargs chmod $PERM
 # or chmod -hR $PERM $DIR_TO_FIX
 --

Waah, SCARY!

Users can create hard links to arbitrary files in that directory, e.g. 
links to other users' private files or to /etc/shadow, and automatically 
get read access to those files.

umask *is* the right solution (together with a sticky-bit dir). Set up a
default umask which allows global read access and *let* users defeat it! If
they know how to change their umask to something more restrictive, they're
bound to know what they're doing!

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: arpwatch and arp packets ...urgent

[Richard Atterer]

On Wed, Feb 18, 2004 at 11:32:00AM +0100, m wrote:
 I want to be able to set public IP's for computers in LAN. Is any
 other solution ? I dont know about it - if you so - please let me know
 :)

Have you tried explicit routing entries for the IPs in question? I'm not 
too sure if this actually works, but if eth1 is the interface on your 
router which is connected to 192.168.0.0/24 and you want to pass on packets 
for 1.2.3.4 to eth1, use this on your router:

  route add -host 1.2.3.4 dev eth0

This assumes that packets destined for 1.2.3.4 are sent to your router, and 
that one host in your LAN is configured to the address 1.2.3.4.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Hacked - is it my turn? - interesting

[Richard Atterer]

On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote:
 No, with REJECT they would show up as closed. DROP produces filtered.

FWIW, you also need --reject-with tcp-reset to fool nmap.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: Hacked - is it my turn? - interesting

[Richard Atterer]

On Tue, Feb 03, 2004 at 05:38:40AM +0100, Philipp Schulte wrote:
 No, with REJECT they would show up as closed. DROP produces filtered.

FWIW, you also need --reject-with tcp-reset to fool nmap.

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯