29 May
2006
29 May
'06
1:54 p.m.
Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend
is postgresql version 8.1.3.
Today I got errors in logfiles, saying:
messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]:
ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in:
http://lists.iptel.org/pipermail/serusers/2005-May/019681.html
with much more detailed description of error, database contents
and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error:
in mysql/val.c function str2val states:
if (!_s) {
memset(_v, 0, sizeof(db_val_t));
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
VAL_NULL(_v) = 0;
and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the:
if (!_s) {
DLOG("str2valp", "got a null value");
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
without explicit notification that this is not-NULL value.
More than, nowhere else in this function VAL_NULL(_v) not set to 0.
So, if a value _v.val contained anyting but 0 at the function start,
resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and
everyting will be ok.
At least for me it's ok for some hours :)
29 May
29 May
5:48 p.m.
This bug has been fixed in stable branch (rev.1.4.2.2 quite some time
ago), but thank you for submission. I will add patch into FreeBSD port.
-Maxim
Alexandre Snarskii wrote:
Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend
is postgresql version 8.1.3.
Today I got errors in logfiles, saying:
messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]:
ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in:
http://lists.iptel.org/pipermail/serusers/2005-May/019681.html
with much more detailed description of error, database contents
and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error:
in mysql/val.c function str2val states:
if (!_s) {
memset(_v, 0, sizeof(db_val_t));
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
VAL_NULL(_v) = 0;
and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the:
if (!_s) {
DLOG("str2valp", "got a null value");
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
without explicit notification that this is not-NULL value.
More than, nowhere else in this function VAL_NULL(_v) not set to 0.
So, if a value _v.val contained anyting but 0 at the function start,
resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and
everyting will be ok.
At least for me it's ok for some hours :)
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
30 Sep
30 Sep
2:20 p.m.
On Mon, May 29, 2006 at 10:48:52AM -0700, Maxim Sobolev wrote:
This bug has been fixed in stable branch (rev.1.4.2.2
quite some time
ago), but thank you for submission. I will add patch into FreeBSD port.
May I humbly ask you to add other diffs between ser-0.9.7 and
0.9.6 modules/postgres as FreeBSD patch too ?
There is at least one remote-triggered stack overflow there
that fixed only in 0.9.7, not exploitable for remote shell, I suppose,
but still source of possible DoS on ser-0.9.6/PostgreSQL installatioins...
PS: if you or other developers interested in details - please,
contact me off-list.
-Maxim
Alexandre Snarskii wrote:
>Hi!
>
>I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend
>is postgresql version 8.1.3.
>
>Today I got errors in logfiles, saying:
>messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]:
> ERROR:avpops:dbrow2avp: dbrow contains NULL fields
>
>The similar problem reported in:
>http://lists.iptel.org/pipermail/serusers/2005-May/019681.html
>with much more detailed description of error, database contents
>and config samples.
>
>Patch is trivial, and looks more like a fix to copy'n'paste error:
>in mysql/val.c function str2val states:
> if (!_s) {
> memset(_v, 0, sizeof(db_val_t));
> VAL_TYPE(_v) = _t;
> VAL_NULL(_v) = 1;
> return 0;
> }
> VAL_NULL(_v) = 0;
>and the last line mentions that 'well, that's value is not NULL'.
>
>In postgresql/db_val.c, line 182, function str2valp, the same statement is
>the: if (!_s) {
> DLOG("str2valp", "got a null value");
> VAL_TYPE(_v) = _t;
> VAL_NULL(_v) = 1;
> return 0;
> }
>without explicit notification that this is not-NULL value.
>More than, nowhere else in this function VAL_NULL(_v) not set to 0.
>So, if a value _v.val contained anyting but 0 at the function start,
>resulting value will be threated as NULL despite the fact, that _s is NOT
>NULL.
>
>Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188)
>and everyting will be ok.
>At least for me it's ok for some hours :)
>
>_______________________________________________
>Serusers mailing list
>Serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
--
Alexandre Snarskii
If you ask a stupid question, you may feel stupid.
If you don't ask a stupid question, you remain stupid.
-Tony Rothman, Ph.D.U. Chicago, Physics
13 Oct
13 Oct
11:07 p.m.
Snar, can you please send me a patch in question? I will be happy to add
it to the port. Thanks!
-Maxim
Alexandre Snarskii wrote:
On Mon, May 29, 2006 at 10:48:52AM -0700, Maxim
Sobolev wrote:
This bug has been fixed in stable branch
(rev.1.4.2.2 quite some time
ago), but thank you for submission. I will add patch into FreeBSD port.
May I humbly ask you to add other diffs between ser-0.9.7 and
0.9.6 modules/postgres as FreeBSD patch too ?
There is at least one remote-triggered stack overflow there
that fixed only in 0.9.7, not exploitable for remote shell, I suppose,
but still source of possible DoS on ser-0.9.6/PostgreSQL installatioins...
PS: if you or other developers interested in details - please,
contact me off-list.
-Maxim
Alexandre Snarskii wrote:
> Hi!
>
> I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend
> is postgresql version 8.1.3.
>
> Today I got errors in logfiles, saying:
> messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]:
> ERROR:avpops:dbrow2avp: dbrow contains NULL fields
>
> The similar problem reported in:
> http://lists.iptel.org/pipermail/serusers/2005-May/019681.html
> with much more detailed description of error, database contents
> and config samples.
>
> Patch is trivial, and looks more like a fix to copy'n'paste error:
> in mysql/val.c function str2val states:
> if (!_s) {
> memset(_v, 0, sizeof(db_val_t));
> VAL_TYPE(_v) = _t;
> VAL_NULL(_v) = 1;
> return 0;
> }
> VAL_NULL(_v) = 0;
> and the last line mentions that 'well, that's value is not NULL'.
>
> In postgresql/db_val.c, line 182, function str2valp, the same statement is
> the: if (!_s) {
> DLOG("str2valp", "got a null value");
> VAL_TYPE(_v) = _t;
> VAL_NULL(_v) = 1;
> return 0;
> }
> without explicit notification that this is not-NULL value.
> More than, nowhere else in this function VAL_NULL(_v) not set to 0.
> So, if a value _v.val contained anyting but 0 at the function start,
> resulting value will be threated as NULL despite the fact, that _s is NOT
> NULL.
>
> Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188)
> and everyting will be ok.
> At least for me it's ok for some hours :)
>
> _______________________________________________
> Serusers mailing list
> Serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
5755
days inactive
6623
days old
3 comments
2 participants
participants (2)
-
Alexandre Snarskii -
Maxim Sobolev