Soekris online kernel debugging via gdb
Hi, On a Soekris box, is it possible to debug a FreeBSD kernel online using remote gdb? I already have the 2ed system to build the image for the soekris anyway, and thus the directory with the sources and symbols. To debug when the target is a traditional PC, I've followed the developers handbook. In those cases, the system had its own keyboard and monitor. Does anything change when the targe is a Soekris box? Also, is using PXE an option? I'd prefer to not have to write a new image to flash each time changes are made to source code. Thanks, MikeC ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 09:20:24PM +0200, Ruslan Ermilov wrote: > If we decide now that our kernel should be C99 clean, we should compile > it with -std=c99, and replace all `__restrict''s in not headers with > C99 `restrict's. $ grep -- -std /sys/conf/* /sys/conf/kern.mk: -fformat-extensions -std=c99 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote patch
On Mon, Jan 19, 2004 at 11:49:35PM +0200, Anton Alin-Adrian wrote: > This patch attempts to implement rfc821 a bit. Also it defines the pos > var as unsigned. Working till now.. Guys? This is *way* off topic for this list. Could you please either discuss this with djb, or just post your patches to ports@, or whatever - as long as you move off this list? Thanks a lot. Bye, Andrea -- Where do you think you're going today? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote patch
This patch attempts to implement rfc821 a bit. Also it defines the pos
var as unsigned. Working till now..
--- qmail-smtpd.c.orig Mon Jun 15 13:53:16 1998
+++ qmail-smtpd.c Mon Jan 19 23:29:35 2004
@@ -1,3 +1,15 @@
+/*
+* This is a patched version of qmail, implementing RFC 821
regarding text line limitations.
+* Developed by Alin-Adrian Anton
([EMAIL PROTECTED],[EMAIL PROTECTED])
+*
+* You may remove this banner if it annoys you. This patch is
public domain, for the
+* benefit of the community.
+*
+* It also fixes an integer overflow in the blast() function.
+ NOTE: it implements the most relaxed RFC821, as it is specified
there.
+*/
+
+
#include "sig.h"
#include "readwrite.h"
#include "stralloc.h"
@@ -48,7 +60,6 @@
void die_control() { out("421 unable to read controls (#4.3.0)\r\n");
flush(); _exit(1); }
void die_ipme() { out("421 unable to figure out my IP addresses
(#4.3.0)\r\n"); flush(); _exit(1); }
void straynewline() { out("451 See
http://pobox.com/~djb/docs/smtplf.html.\r\n";); flush(); _exit(1); }
-
void err_bmf() { out("553 sorry, your envelope sender is in my
badmailfrom list (#5.7.1)\r\n"); }
void err_nogateway() { out("553 sorry, that domain isn't in my list of
allowed rcpthosts (#5.7.1)\r\n"); }
void err_unimpl() { out("502 unimplemented (#5.5.1)\r\n"); }
@@ -58,7 +69,7 @@
void err_noop() { out("250 ok\r\n"); }
void err_vrfy() { out("252 send some mail, i'll try my best\r\n"); }
void err_qqt() { out("451 qqt failure (#4.3.0)\r\n"); }
-
+void err_longline() { out("500 Line too long, please read RFC
821.\r\n"); flush(); _exit(1); }
stralloc greeting = {0};
@@ -293,10 +304,46 @@
void blast(hops)
int *hops;
{
+
+/*
+*RFC 821 August 1982
+* Simple Mail Transfer Protocol
+*
+*text line
+*
+* The maximum total length of a text line including the
+*is 1000 characters (but not counting the leading
+* dot duplicated for transparency).
+*
+*recipients buffer
+*
+* The maximum total number of recipients that must be
+* buffered is 100 recipients.
+*
+*
+*
+* * *
+* * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+* * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+* * OF THESE OBJECTS SHOULD BE USED.*
+* * *
+*
+*
+* Errors due to exceeding these limits may be reported by using
+* the reply codes, for example:
+*
+*500 Line too long.
+*
+*501 Path too long
+*
+*552 Too many recipients.
+*
+*552 Too much mail data.
+*/
char ch;
int state;
int flaginheader;
- int pos; /* number of bytes since most recent \n, if fih */
+ unsigned int pos; /* number of bytes since most recent \n, if fih */
int flagmaybex; /* 1 if this line might match RECEIVED, if fih */
int flagmaybey; /* 1 if this line might match \r\n, if fih */
int flagmaybez; /* 1 if this line might match DELIVERED, if fih */
@@ -317,7 +364,8 @@
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
}
- ++pos;
+if (++pos>65535-1) err_longline(); /* will bail out nicely with
err 500 */
+
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez =
1; }
}
switch(state) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
Dinesh Nair wrote:
On Mon, 19 Jan 2004, Anton Alin-Adrian wrote:
Regarding latest qmail vulnerability, I coded this quickly patch.
Please double-check me if I am wrong here. Forward this to
freebsd-security please.
320c320
< ++pos;
---
if (pos>9) ++pos;
http://www.guninski.com/qmailcrash.html
woulnd't it be better to switch pos from an int to a u_int ? or do
specific bounds checking before incrementing pos ? this patch seems to
_only_ increment pos if it's > 9, and reading the code will show you where
you're going to get into some problems. :)
Regards, /\_/\ "All dogs go to heaven."
[EMAIL PROTECTED](0 0)http://www.alphaque.com/
+==oOO--(_)--OOo==+
| for a in past present future; do|
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |
+=+
Please look in the thread, I already posted:
--- qmail-smtpd.c Mon Jun 15 13:53:16 1998
+++ qmail-smtpd-patched.c Mon Jan 19 15:22:23 2004
@@ -316,8 +316,8 @@
if (flagmaybex) if (pos == 7) ++*hops;
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
+ ++pos;
}
- ++pos;
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez = 1; }
}
switch(state) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 08:17:19AM -0800, David O'Brien wrote: > On Mon, Jan 19, 2004 at 02:41:26PM +0100, Harti Brandt wrote: [...] > > What about third party code that reads cdefs.h and is pre-c99? It's > > perfectly ok to use restrict as a name there. > > Its also perfectly OK to use 'exp' as a varible, but we've been getting > rid of those because they are difficult to deal with. The same is true > of older C++ code when new reserved words were added. Sometimes one has > to move forward to the modern world. This is all congecture -- can you > find one thing in /usr/ports that uses restrict as a symbol? > This is not the point. The point was if we want to stay C89 compatible or not. If we decide at some point that FreeBSD should no longer accept valid C89 code, this change is probably ok. If we decide now that our kernel should be C99 clean, we should compile it with -std=c99, and replace all `__restrict''s in not headers with C99 `restrict's. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: qmail remote root patch
On Mon, 19 Jan 2004, Anton Alin-Adrian wrote: > > Regarding latest qmail vulnerability, I coded this quickly patch. > > Please double-check me if I am wrong here. Forward this to > > freebsd-security please. > >320c320 > >< ++pos; > >--- > > > > > >> if (pos>9) ++pos; > http://www.guninski.com/qmailcrash.html woulnd't it be better to switch pos from an int to a u_int ? or do specific bounds checking before incrementing pos ? this patch seems to _only_ increment pos if it's > 9, and reading the code will show you where you're going to get into some problems. :) Regards, /\_/\ "All dogs go to heaven." [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo "The opinions here in no way reflect the opinions of my $a $b." | | done; done | +=+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 02:41:26PM +0100, Harti Brandt wrote: > On Sat, 17 Jan 2004, David O'Brien wrote: > > DO>On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: > DO>> >No, we should be using the __restrict as coded. But I wonder why > DO>> >we can't just use "restrict"... > DO>> > DO>> Because that would really mess up any user program that used > DO>> 'restrict' as a variable or function name. I think the > DO>> current approach is the best. > DO> > DO>Such code isn't portable to C99, which is still a goal of ours. I like > DO>RU's suggestion, because it is straight C[99] code and not an > DO>abstraction. I'll do a 'make world' test and see if we'd have trouble > DO>with RU's form. > > What about third party code that reads cdefs.h and is pre-c99? It's > perfectly ok to use restrict as a name there. Its also perfectly OK to use 'exp' as a varible, but we've been getting rid of those because they are difficult to deal with. The same is true of older C++ code when new reserved words were added. Sometimes one has to move forward to the modern world. This is all congecture -- can you find one thing in /usr/ports that uses restrict as a symbol? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[REVISED] Re: qmail remote root patch
The last patch I sent to the list is incomplete because it did not handle
the case where there's too many short DELIVERED or RECEIVED lines, which
still has potential to cause memory overwrites.
I hope this time the exploit potential is completely eliminated.
Cheers,
Xin LI
--- qmail-smtpd.c.orig Mon Jan 19 23:20:38 2004
+++ qmail-smtpd.c Mon Jan 19 23:22:36 2004
@@ -305,7 +305,7 @@
*hops = 0;
flaginheader = 1;
pos = 0; flagmaybex = flagmaybey = flagmaybez = 1;
- for (;;) {
+ for (;;((*hops) < MAXHOPS)) {
substdio_get(&ssin,&ch,1);
if (flaginheader) {
if (pos < 9) {
@@ -317,7 +317,17 @@
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
}
- ++pos;
+ if((++pos) > 1000) {
+ /*
+ * RFC 2821 has explicitly defined a text line can contain
+ * 1000 characters at maximium. This is a workaround to
+ * stop copying characters there, but I am not sure about
+ * the side effect. Consider this as an attack and set hops
+ * to MAXHOPS to prevent future processing.
+ */
+ *hops = MAXHOPS;
+ break;
+ }
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez =
1; }
}
switch(state) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CHECKER] bugs in FreeBSD
On Sun, Jan 18, 2004 at 05:44:52PM -0500, Matthew N. Dodd wrote: > On Sun, 18 Jan 2004, Ruslan Ermilov wrote: > > But we're missing the proper NULL checking, here's the fix: > ... > > I've already dealt with this. > Neat, this works much better! Can you please propagate your fix to dev/iir/iir.c:iir_attach()? Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Real Time FreeBSD?!!!
Dude, could you rephrase that? Its a bit hard to understand On Sun, 18 Jan 2004 04:09 pm, sam Long wrote: > I have a system FreeBSD 5.1-p11. > How will develop further FreeBSD? > How real time is possible to make from FreeBSD > operational system? > I know, that in FreeBSD there are expansions real time > of standard POSIX. > > I have a small kernel of system due to modules, but on > how many stably such > kernel? > What problems can be?I have born all modules for > limits of a kernel. > > Thank you for the help Den. > > __ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Real Time FreeBSD?!!!
I have a system FreeBSD 5.1-p11. How will develop further FreeBSD? How real time is possible to make from FreeBSD operational system? I know, that in FreeBSD there are expansions real time of standard POSIX. I have a small kernel of system due to modules, but on how many stably such kernel? What problems can be?I have born all modules for limits of a kernel. Thank you for the help Den. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status GBDE attach at boot
On Sun, Jan 18, 2004 at 02:43:42PM +0100, Simon L. Nielsen wrote: > On 2004.01.17 14:53:58 -0500, Allan Fields wrote: > > Hi, > > > > I'm interested to know what may be in the pipeline as far as GBDE > > boot time attach/automation support. Has anyone committed to > > implementing these features? (I don't see it anymore (on the 5.3 > > todo list) in releng pages.) > > 5.2 already has support for attaching GBDE volumes at boot by using the > /etc/rc.d/gbde script. I have been using it for a while, and it works > OK. Ahh.. ok, didn't see the changes yet. That is a straight forward approach - could there just as easily be a similar facility for other geoms? > I sent a patch yesterday to the freebsd-rc mailing list make the gbde > rc.d script work a bit better (see > http://groups.yahoo.com/group/FreeBSD-rc/message/659 ). > > > As a fstab is concerned with mount hack, this is the right approach > > I think it's better to just use a rc.d script to attach gbde volumes > before the normal filesystem mount, since it seems more "clean". Of This is good including specifying lockfile dir, but implies passphrase entry before continuing on always the console? Which brings us to passphrase from file/filedesc issue vs. from tty / on command line. Could password prompts be read from another terminal or from secure source like key device or remote terminal while the booting continues in the mean-time? > course the rc.d script could be enhanced e.g. to support random keys, > like your "temp" feature. Yup. Idea was raised previously on the lists by lucky and phk. Seems like a good idea for swap,/tmp setup. > -- > Simon L. Nielsen > FreeBSD Documentation Team Allan Fields ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root final patch
--- qmail-smtpd.c Mon Jun 15 13:53:16 1998
+++ qmail-smtpd-patched.c Mon Jan 19 15:22:23 2004
@@ -316,8 +316,8 @@
if (flagmaybex) if (pos == 7) ++*hops;
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
+ ++pos;
}
- ++pos;
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez =
1; }
}
switch(state) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
This is the patch I am currently using, for qmail-smtpd.c . I don't dare to touch RFC because I did not carefully read qmail sources and I am not aware of details/impact. I think this patch is good enough to simply remove the vulnerability. I now looked more thoroughly at the code and ask other's opinions. I think this is really ok patch.. Regards, Alin. 318a319 > ++pos; 320d320 < ++pos; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: __restrict__ vs __restrict ?
On Sat, 17 Jan 2004, David O'Brien wrote: DO>On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: DO>> >No, we should be using the __restrict as coded. But I wonder why DO>> >we can't just use "restrict"... DO>> DO>> Because that would really mess up any user program that used DO>> 'restrict' as a variable or function name. I think the DO>> current approach is the best. DO> DO>Such code isn't portable to C99, which is still a goal of ours. I like DO>RU's suggestion, because it is straight C[99] code and not an DO>abstraction. I'll do a 'make world' test and see if we'd have trouble DO>with RU's form. What about third party code that reads cdefs.h and is pre-c99? It's perfectly ok to use restrict as a name there. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
On page 54 of RFC2821, a text line should be shorter than 1000 characters if
I did not misunderstood it. So I'd proposal the following patch, which
mitigate the issue by rejecting anything which contains RFC-violation.
Cheers,
Xin LI
--- qmail-smtpd.c.orig Mon Jan 19 21:08:35 2004
+++ qmail-smtpd.c Mon Jan 19 21:38:31 2004
@@ -317,7 +317,17 @@
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
}
- ++pos;
+ if((++pos) > 1000) {
+ /*
+ * RFC 2821 has explicitly defined a text line can contain
+ * 1000 characters at maximium. This is a workaround to
+ * stop copying characters there, but I am not sure about
+ * the side effect. Consider this as an attack and set hops
+ * to MAXHOPS to prevent future processing.
+ */
+ *hops = MAXHOPS;
+ break;
+ }
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez =
1; }
}
switch(state) {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
Anton Alin-Adrian wrote:
Anton Alin-Adrian wrote:
Regarding latest qmail vulnerability, I coded this quickly patch.
Please double-check me if I am wrong here. Forward this to
freebsd-security please.
Regards,
Alin.
320c320
< ++pos;
---
if (pos>9) ++pos;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
I forgot to mention about vuln:
http://www.guninski.com/qmailcrash.html
Actually that was utterly wrong. I think this works:
bash-2.05b$ diff -a qmail-smtpd.c qmail-smtpd-patched.c
318a319
> ++pos;
320d320
< ++pos;
The patched function will look like:
void blast(hops)
int *hops;
{
char ch;
int state;
int flaginheader;
int pos; /* number of bytes since most recent \n, if fih */
int flagmaybex; /* 1 if this line might match RECEIVED, if fih */
int flagmaybey; /* 1 if this line might match \r\n, if fih */
int flagmaybez; /* 1 if this line might match DELIVERED, if fih */
state = 1;
*hops = 0;
flaginheader = 1;
pos = 0; flagmaybex = flagmaybey = flagmaybez = 1;
for (;;) {
substdio_get(&ssin,&ch,1);
if (flaginheader) {
if (pos < 9) {
if (ch != "delivered"[pos]) if (ch != "DELIVERED"[pos])
flagmaybez = 0;
if (flagmaybez) if (pos == 8) ++*hops;
if (pos < 8)
if (ch != "received"[pos]) if (ch != "RECEIVED"[pos])
flagmaybex = 0;
if (flagmaybex) if (pos == 7) ++*hops;
if (pos < 2) if (ch != "\r\n"[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
++pos;
}
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez = 1; }
}
switch(state) {
case 0:
if (ch == '\n') straynewline();
if (ch == '\r') { state = 4; continue; }
break;
case 1: /* \r\n */
if (ch == '\n') straynewline();
if (ch == '.') { state = 2; continue; }
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 2: /* \r\n + . */
if (ch == '\n') straynewline();
if (ch == '\r') { state = 3; continue; }
state = 0;
break;
case 3: /* \r\n + .\r */
if (ch == '\n') return;
put(".");
put("\r");
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 4: /* + \r */
if (ch == '\n') { state = 1; break; }
if (ch != '\r') { put("\r"); state = 0; }
}
put(&ch);
}
}
So what I did is move ++pos; into the if (pos < 9) block. Originally it
is right after the } ending that block.
This works if pos gets incremented as
pos=1,2,.9,10,...,max,...,upper-overflow(negative).
This utterly fails if pos is not incremented like that.
Any ideas? I think it works, after a first look at the incrementation loop.
Sorry for all other mails, I am stressed . (need to calm down i know)
Alin.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
Sorry I don't think so. This will cause pos to stay at 0 and therefore infinitely loop. I am working on a new patch. Cheers, Xin LI - Original Message - From: "Anton Alin-Adrian" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 19, 2004 8:42 PM Subject: qmail remote root patch > Regarding latest qmail vulnerability, I coded this quickly patch. Please > double-check me if I am wrong here. Forward this to freebsd-security please. > > > Regards, > Alin. > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: qmail remote root patch
Anton Alin-Adrian wrote: Regarding latest qmail vulnerability, I coded this quickly patch. Please double-check me if I am wrong here. Forward this to freebsd-security please. Regards, Alin. 320c320 < ++pos; --- if (pos>9) ++pos; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I forgot to mention about vuln: http://www.guninski.com/qmailcrash.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
qmail remote root patch
Regarding latest qmail vulnerability, I coded this quickly patch. Please double-check me if I am wrong here. Forward this to freebsd-security please. Regards, Alin. 320c320 < ++pos; --- > if (pos>9) ++pos; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [CHECKER] bugs in FreeBSD
On Sun, 18 Jan 2004, Matthew Dillon wrote: > Well, this is fun. There are over 460 files in the 5.x source tree > (360 in DFly) that make calls to malloc(... M_NOWAIT), and so far > about 80% of the calls that I've reviewed generate inappropriate > side effects when/if a failure occurs. CAM is the biggest violator... > it even has a few panic() conditionals if a malloc(... M_NOWAIT) fails. > Not Fun! I keep getting the urge to write a simple failure generator for malloc / m_get / etc that would compare the caller's address to a linked list of previous callers so that you could ensure that you would get exactly one failure returned to malloc() call in the system. This would guarantee better coverage than random failures, which aren't likely to find the bulk of the failure cases. Another interesting debug idea would be to extend the above idea, and have seperate malloc buckets for each caller, along with cookies / canary values before and after each piece of data; this could be used to figure out *exactly* which function is causing memory corruption. Of course, I found so many problems when I wrote the MBUF_STRESS_TEST code that I really don't want to think about how long fixing all the bugs exposed by the above two tests would take. Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
