 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
http://www.us-cert.gov/cas/techalerts/TA04-217A.html
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
maybe if you'd run a POV-Ray server.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It looks like these vulnerabilities all have to do with the reading of a PNG
image. If it is vulnerable, it would only be so if a user were to take a PNG
image provided by someone and use it as, say, an image_map in a scene which
they rendered.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Why I'm not surprised to see the term "buffer overflow" there?
We are currently living in the year 2004, not 1980. We have have at least
30 years of experience about buffer overflow exploits. And still people
out there are writing code where buffer overflows are possible.
And these people seriously think they know how to code. Yeah.
--
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
war### [at] tag povrayorg news:4111f2aa@news.povray.org
> We are currently living in the year 2004, not 1980. We have have at
> least
> 30 years of experience about buffer overflow exploits. And still
> people out there are writing code where buffer overflows are possible.
> And these people seriously think they know how to code. Yeah.
Indeed... I dont understand how it is possible accessing memory of other
process by pointer mistake (imho OS should disallow this) or writting any
code-pages, even own...
Perhaps grSecurity / SeLinux prevent that bug from corrupting code and make
it almost useless?
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Program ended abnormally on 04/08/2004 21:49, Due to a catastrophic Eli error:
> maybe if you'd run a POV-Ray server.
>
>
Sorry to be blunt, but this reply proves that you don't understand the
vulnerability. Slime explains what is the risk and it has absolutely nothing to
do with servers.
Maybe I should have asked if the POV team was planning on releasing a patch that
uses a patched version of LibPNG.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4112d4b1$1@news.povray.org> , Francois Labreque
<fla### [at] videotronca> wrote:
> Program ended abnormally on 04/08/2004 21:49, Due to a catastrophic Eli error:
>
>> maybe if you'd run a POV-Ray server.
>>
> Sorry to be blunt, but this reply proves that you don't understand the
> vulnerability. Slime explains what is the risk and it has absolutely nothing
> to do with servers.
No, he understood perfectly. There is no serious problem in the PNG library
at all. Nothing to jump up and down like crazy. The media currently does
it for every tiny bug found because of some script kids writing
Outlook-based worms. Yet, the one has hardly anything to do with the other.
> Maybe I should have asked if the POV team was planning on releasing a patch
> that uses a patched version of LibPNG.
The probability that anything will happen to your system because of this
little bug in the PNG library when using POV-Ray is close to zero. There is
no reason to join the hype. The next regular bugfix release of POV-Ray will
use the next version of the PNG library. No need to rush anything.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Program ended abnormally on 06/08/2004 03:02, Due to a catastrophic Thorsten
Froehlich error:
> The next regular bugfix release of POV-Ray will
> use the next version of the PNG library. No need to rush anything.
>
That's all you needed to answer. There was no need to imply that I was "jumping
up and down like crazy".
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* videotron.ca */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dne### [at] sanrrcom news:41125547$1@news.povray.org
> That's not the problem. The problem is overwriting a portion of the (for
> example) povray executable such that it turns into a call to delete
> files, for example.
>
> > (imho OS should disallow this)
>
> The OS shouldn't have to, except that people use programming languages
> vulnerable to such. ;-) All those nasty pointers and such.
I think You are a bit wrong, OS should dissalow to change own *executable*
- to change the code page, it shoukd only allow to change own data page.
Such thingy is implemeneted as PaX in grSecurity for Linux.
When using it correclty any program can not modyfie source either loaded
into memory or stored on HDD of it self or other programs - so he can not
instert stystem("rm -rf /"); call.
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
dne### [at] sanrrcom news:4119a516$1@news.povray.org
> There's two steps you need to take, and that's only one of them. The
> other is to disallow executing data pages.
I realy think grSec does that
> And of course, if you manage to (say) corrupt the Perl code stored in
> data by finding a bug in the Perl interpreter, you can have the Perl
> interpreter think you coded a nasty call into your Perl source.
> I can't imagine it can cure all security holes.
Ofcourse, nothing cures them all ;)
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
