Martin Pitt wrote:
After discovering that the same flawed multiplication is also present
in upstream's other two patches, I decided to completely rework the
patch.
I attach the debdiff with separated out changelog. Florian, maybe you
can peer-review the patch?
Martin and
Hi Frank, hi Joey!
Frank Küster [2005-12-09 19:01 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
After discovering that the same flawed multiplication is also present
in upstream's other two patches, I decided to completely rework the
patch.
I attach the debdiff with separated out
Hi!
Frank Küster [2005-12-08 15:54 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
- img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
-sizeof(JPXTile));
+ nTiles = img.nXTiles * img.nYTiles;
+ // check for overflow before allocating
Hi Frank!
Frank Küster [2005-12-08 13:17 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
Hi!
I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).
Can you please
Hi Florian, hi Frank!
Frank Küster [2005-12-08 22:55 +0100]:
Florian Weimer [EMAIL PROTECTED] wrote:
By the way, the gmallocn function suffers from undefined integer
overflow, too:
void *gmallocn(int nObjs, int objSize) {
int n;
n = nObjs * objSize;
if (objSize == 0 || n /
Martin Pitt [EMAIL PROTECTED] wrote:
Hi Florian, hi Frank!
Frank Küster [2005-12-08 22:55 +0100]:
Florian Weimer [EMAIL PROTECTED] wrote:
By the way, the gmallocn function suffers from undefined integer
overflow, too:
void *gmallocn(int nObjs, int objSize) {
int n;
n = nObjs
Hi!
Frank Küster [2005-12-09 11:09 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
Hi Florian, hi Frank!
Frank Küster [2005-12-08 22:55 +0100]:
Florian Weimer [EMAIL PROTECTED] wrote:
By the way, the gmallocn function suffers from undefined integer
overflow, too:
void
* Martin Pitt:
- For invalid (big) positive values of nObjs which, when multiplied with nObjs
overflow an int, we have two cases:
But neither ISO C nor GNU C make any promises regarding this case.
Overflow is undefined, period.
You can pass -fwrapv to gcc if you want modulo arithmetic for
Hi Florian!
Florian Weimer [2005-12-09 11:53 +0100]:
* Martin Pitt:
- For invalid (big) positive values of nObjs which, when multiplied with
nObjs
overflow an int, we have two cases:
But neither ISO C nor GNU C make any promises regarding this case.
Overflow is undefined, period.
* Martin Pitt:
Hi Florian!
Florian Weimer [2005-12-09 11:53 +0100]:
* Martin Pitt:
- For invalid (big) positive values of nObjs which, when multiplied with
nObjs
overflow an int, we have two cases:
But neither ISO C nor GNU C make any promises regarding this case.
Overflow is
Hi Frank, hi Florian!
Frank Küster [2005-12-08 13:17 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
Hi!
I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).
Martin Pitt [EMAIL PROTECTED] wrote:
After discovering that the same flawed multiplication is also present
in upstream's other two patches, I decided to completely rework the
patch.
I attach the debdiff with separated out changelog. Florian, maybe you
can peer-review the patch?
Martin and
Martin Pitt [EMAIL PROTECTED] wrote:
Hi!
I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).
Can you please check that you indeed fixed (tetex-bin)/will fix
Hi Frank!
Frank Küster [2005-12-08 13:17 +0100]:
Martin Pitt [EMAIL PROTECTED] wrote:
Hi!
I'm currently preparing Ubuntu security updates for these issues, and
I noticed that the upstream provided patch is wrong. I sent the mail
below to upstream (and some others).
Can you please
Hi Frank!
Frank Küster [2005-12-08 13:17 +0100]:
We have the same flaw in our upload. Would you be so kind and check the
updated patch at
http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/patches/patch-CVE-2005-3191+2+3?op=filerev=0sc=0
I'm completely illerate in C++, and
Martin Pitt [EMAIL PROTECTED] wrote:
- img.tiles = (JPXTile *)gmalloc(img.nXTiles * img.nYTiles *
- sizeof(JPXTile));
+ nTiles = img.nXTiles * img.nYTiles;
+ // check for overflow before allocating memory
+ if (nTiles == 0 || nTiles /
On Dec 08 2005, Martin Pitt wrote:
(who really wishes upstreams would switch to poppler after uploading
22 security update packgages)
Yes, but poppler is still not exactly a complete replacement for
xpdf---at least, that is what I understand from this bug of mine:
http://bugs.debian.org/340379
Rogério Brito [EMAIL PROTECTED] wrote:
On Dec 08 2005, Martin Pitt wrote:
(who really wishes upstreams would switch to poppler after uploading
22 security update packgages)
Yes, but poppler is still not exactly a complete replacement for
xpdf---at least, that is what I understand from this
Martin Pitt [EMAIL PROTECTED] wrote:
OK, you can now find the 3.0 debdiff at
http://patches.ubuntu.com/patches/tetex-bin.CVE-2005-3191_2_3.diff
Thank you, I've added this.
it might be interesting for you to get the CVE numbers in the
changelog right. (Please do mention the CVE numbers
* Frank Küster:
It also seems that there are some buffer overflows in 3.00 that do not
have any tests, e.g. in XRef.cc, line 391 after patch-CAN-2004-0888 has
been applied. Or is such a check
if (newSize 0) {
goto err1;
}
enough to detect an integer overflow, because
* Frank Küster:
Would
if (nTiles = INT_MAX / sizeof(JPXTile) {
error(getPos(), Bad tile count in JPX SIZ marker segment);
return gFalse;
be okay?
It might still be a DoS issue, I think. Allocating arbitrary amounts
of memory upon user request is usually a bad idea.
Florian Weimer [EMAIL PROTECTED] wrote:
* Frank Küster:
Would
if (nTiles = INT_MAX / sizeof(JPXTile) {
error(getPos(), Bad tile count in JPX SIZ marker segment);
return gFalse;
be okay?
It might still be a DoS issue, I think. Allocating arbitrary amounts
of memory
* Frank Küster:
The function that is called in *tetex-bin* is not gmallocn, but gmalloc
- it's based on xpdf 3.00, not 3.01, and this is the very reason why I
need to check for an overflow in nTiles * sizeof(JPXTile).
Sure, I wanted to explain why this is not sufficient. It should be
23 matches
Mail list logo
