Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Once you understand how the scattering integrals work it's natural to compute them also from the outside of the atmosphere. Okay, now I am *really* confused. Are we trying to solve the same problem? Light scattering in the atmosphere is not part of what Earthview does at all. That is currently solved by the scattering part of the skydome shader Lauri has originally written (and which I have modified to include a haze layer and lightfields), this shader works inside the atmosphere and reasonably well outside of it (apart from a few quirks). Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. Apart from the fact that both somehow have to do with spaceflight, there doesn't seem to be any overlap at all?! * Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
On Tue, 2012-03-20 at 08:15 +, Renk Thorsten wrote: Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. I was wondering, instead of using the Blue Marble texture it might be a good idea to render our own texture using the global scenery. This prevents license issues and make for a nice transition between the lower landclass scenery and a global sphere at some altitude. Erik -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Erik Hofman wrote: On Tue, 2012-03-20 at 08:15 +, Renk Thorsten wrote: Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. I was wondering, instead of using the Blue Marble texture it might be a good idea to render our own texture using the global scenery. This prevents license issues and make for a nice transition between the lower landclass scenery and a global sphere at some altitude. Well, it doesn't need to be the Blue Marble as a texture, but it's proven to be a good start. Indeed, the process of Marble-textured tiles getting gradually replaced by 'real' Scenery (Mathias' approach) is obvious, but I think our Scenery is the culprit, not the Marble ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities
Hi Curtis,
Here I send details about buffer overflows I commented before:
The first one is in flightgear/src/FDM/YASim/Rotor.cpp
line 271 int Rotor::getValueforFGSet(int j,char *text,float *f)
{
.
.
.
line 277 sprintf(text,/rotors/%s/cone-deg, _name);
line 287 sprintf(text,/rotors/%s/roll-deg, _name);
.
.
.
And every similar sprintf in the function getValueforFGSet which copies
_name string inside text buffer. If rotor's name is very long for example
in fgdata/Aircraft/bo105/bo105.xml:
rotor name=AA..AA x=-2.75 y=0.0 z=1.55
nx=0.05 ny=0 nz=1. fx=1 fy=0 fz=0 ccw=1
then string AA..AA will overflow text buffer
(256 bytes), which could allow local arbitrary code execution by a
corrupted xml model with rotor tag.
The second one is in simgear/simgear/simgear/io/sg_socket_udp.cxx:
line 101 int SGSocketUDP::read( char *buf, int length ) {
.
.
.
line 108 if ( (result = sock.recv(buf, SG_IO_MAX_MSG_SIZE, 0)) = 0 ) {
If buf size is less than SG_IO_MAX_MSG_SIZE, then such buffer is going to
be overflowed, which could allow even remote arbitrary code execution.
However I'm wondering if that code section is being used for flightgear at
all. It seems that It is not. Looking at google I found a project using
that simgear code section:
http://forge.scilab.org/index.php/p/aerospace-toolbox/
forge.scilab.org/index.php/p/aerospace-toolbox/source/file/277c4d9fd4a7d23dedef34919c100c80c893e983/sci_gateway/cpp/sci_cpp_find.cxx
Regards,
Andres Gomez
2012/3/13 Curtis Olson curtol...@gmail.com
Hi Andres,
Yes I saw your email, but I'm traveling this week and away from my desktop
computer and all of the code. I was hoping one of the other developers
would pick this up and look at it ... otherwise remind me next week after
I've had a few days to catch up from being gone.
Regards,
Curt.
On Mar 13, 2012 9:57 AM, Andres Gomez ago...@fluidsignal.com wrote:
**
Hi Curtis,
*Are you flightgear's project manager, right?
Did you see last email I sent to devel list about several vulnerabilities
in flightgeat? I had no answer so I'm writing you in case you didn't see
it.
By the way I recently have also found a couple of buffer overflows.
Regards.
*
2012/3/9 Andres Gomez ago...@fluidsignal.com
Hi,
I have found multiple format string vulnerabilities in Flightgear and
Simgear. This could allow an attacker to execute arbitrary code in a
Flightgear user's machine. This is possible because user controlled format
string is passed directly to printf family functions without any
validation. For example if I have an aircraft xml model with a section
like this:
text
nameRegistration/name
type type=stringtext-value/type
property type=string/sim/multiplay/callsign/property
format type=string%s/format
draw-text type=booltrue/draw-text
.
.
.
/text
the format string %s in label
format type=string%s/format
is passed directly to snprintf. This line can be changed for something
like %s %s %s %s which will make Flightgear to crash. Even more if %n
specifier* *is used, arbitrary code execution can be achieved. Until
now I have found this issue in the following files:
fgfs/flightgear/src/Cockpit/panel.cxx:1237
fgfs/flightgear/src/Cockpit/panel.cxx:1240
fgfs/flightgear/src/Cockpit/panel.cxx:1245
fgfs/flightgear/src/Network/generic.cxx:222
simgear/simgear/scene/model/SGText.cxx:72
simgear/simgear/scene/model/SGText.cxx:74
but others locations could also be affected. A solution for this bug
would be at least to validate that n specifier is not present in the
format string.
Regards,
Andrés Gómez
--
AVISO DE CONFIDENCIALIDAD:
Esta transmisión se entiende para uso del destinatario o la entidad a la
que va dirigida y puede contener información confidencial o protegida por
la ley. Si el lector de este mensaje no fuera el destinatario, considérese
por este medio informado que la retención, difusión, o copia de este correo
electrónico está estrictamente prohibida. Si recibe este mensaje por error,
por favor notifique inmediatamente al emisor y destruya el original. Gracias
--
CONFIDENTIALITY NOTICE:
This transmission is intended for the use of the individual or entity to
which it is addressed, and it may contain information that is confidential
or privileged under law. If the reader of this message is not the intended
recipient, you are hereby notified that retention, dissemination,
distribution or copying of this e-mail is strictly prohibited. If you
received this e-mail in error, please notify the sender immediately and
destroy the original. Thank you.
--
--
AVISO DE CONFIDENCIALIDAD:
Esta transmisión se entiende para uso del destinatario o la entidad a la
que va dirigida y puede contener
Re: [Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities
Hi Andres,
thanks for pointing these out. We have been chasing and replacing
(s)(n)printfs in our code over the years but not at a high priority.
Everytime I (and others) are working on a file and stumble upon a
printf, we try to replace this with more robust code.
This is low priority, because the possible code injection can only
happen by the user itself and usually not over the (inter)net. And
FlightGear is supposed to run in the user's context which should add
some extra safety. (Never run fgfs as root or Administrator!)
But anyway, these are bad coding styles and should be replaced, the
sooner the better.
Torsten
Am 20.03.2012 18:18, schrieb Andres Gomez:
Hi Curtis,
Here I send details about buffer overflows I commented before:
The first one is in flightgear/src/FDM/YASim/Rotor.cpp
line 271 int Rotor::getValueforFGSet(int j,char *text,float *f)
{
.
.
.
line 277 sprintf(text,/rotors/%s/cone-deg, _name);
line 287 sprintf(text,/rotors/%s/roll-deg, _name);
.
.
.
And every similar sprintf in the function getValueforFGSet which copies
_name string inside text buffer. If rotor's name is very long for
example in fgdata/Aircraft/bo105/bo105.xml:
rotor name=AA..AA x=-2.75 y=0.0
z=1.55 nx=0.05 ny=0 nz=1. fx=1 fy=0 fz=0 ccw=1
then string AA..AA will overflow text
buffer (256 bytes), which could allow local arbitrary code execution by
a corrupted xml model with rotor tag.
The second one is in simgear/simgear/simgear/io/sg_socket_udp.cxx:
line 101 int SGSocketUDP::read( char *buf, int length ) {
.
.
.
line 108 if ( (result = sock.recv(buf, SG_IO_MAX_MSG_SIZE, 0)) = 0 ) {
If buf size is less than SG_IO_MAX_MSG_SIZE, then such buffer is going
to be overflowed, which could allow even remote arbitrary code
execution. However I'm wondering if that code section is being used for
flightgear at all. It seems that It is not. Looking at google I found a
project using that simgear code section:
http://forge.scilab.org/index.php/p/aerospace-toolbox/
forge.scilab.org/index.php/p/aerospace-toolbox/source/file/277c4d9fd4a7d23dedef34919c100c80c893e983/sci_gateway/cpp/sci_cpp_find.cxx
http://forge.scilab.org/index.php/p/aerospace-toolbox/source/file/277c4d9fd4a7d23dedef34919c100c80c893e983/sci_gateway/cpp/sci_cpp_find.cxx
Regards,
Andres Gomez
2012/3/13 Curtis Olson curtol...@gmail.com mailto:curtol...@gmail.com
Hi Andres,
Yes I saw your email, but I'm traveling this week and away from my
desktop computer and all of the code. I was hoping one of the other
developers would pick this up and look at it ... otherwise remind me
next week after I've had a few days to catch up from being gone.
Regards,
Curt.
On Mar 13, 2012 9:57 AM, Andres Gomez ago...@fluidsignal.com
mailto:ago...@fluidsignal.com wrote:
**
Hi Curtis,
*Are you flightgear's project manager, right?
Did you see last email I sent to devel list about several
vulnerabilities in flightgeat? I had no answer so I'm writing
you in case you didn't see it.
By the way I recently have also found a couple of buffer overflows.
Regards.
*
2012/3/9 Andres Gomez ago...@fluidsignal.com
mailto:ago...@fluidsignal.com
Hi,
I have found multiple format string vulnerabilities in
Flightgear and Simgear. This could allow an attacker to
execute arbitrary code in a Flightgear user's machine. This
is possible because user controlled format string is passed
directly to printf family functions without any validation.
For example if I have an aircraft xml model with a section
like this:
text
nameRegistration/name
type type=stringtext-value/type
property type=string/sim/multiplay/callsign/property
format type=string%s/format
draw-text type=booltrue/draw-text
.
.
.
/text
the format string %s in label
format type=string%s/format
is passed directly to snprintf. This line can be changed for
something like %s %s %s %s which will make Flightgear to
crash. Even more if %n specifier//is used, arbitrary code
execution can be achieved. Until now I have found this issue
in the following files:
fgfs/flightgear/src/Cockpit/panel.cxx:1237
fgfs/flightgear/src/Cockpit/panel.cxx:1240
fgfs/flightgear/src/Cockpit/panel.cxx:1245
[Flightgear-devel] Performance issue with sim reset vs Nasal
Hi,
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to trigger some initialization code. It's fine to do so. However,
modules need to be aware that this signal triggers on _every_ simulator
reset. So, the connected code executes every time you hit Shift-ESC, use
the Relocate-in-air or Relocate-on-ground dialogs.
We had plenty of places were init code connected to
/sim/signals/fdm-initialized installed a fresh set of listeners or
started another timer-driven update loop. This results in performance
degrading with every sim reset.
The worst case scenario looks like this:
_setlistener(/sim/signals/fdm-initialized, func {
setlistener(/sim/foo, foo);
setlistener(/sim/bar, bar);
update_loop();
}
var update_loop = func {
...
settimer(update_loop,0);
}
= Initially 'foo' and 'bar' are called once whenever their respective
listener triggers. After the 2nd sim reset, they are called twice per
change, after the 10th reset they are called 10 times for each property
change.
Similar issue with update_loop: initially there's only one timer
running. After the 10th reset, there's already 10 concurrent loops...
I've fixed the issue in several places of our generic Nasal modules (so
this affected every aircraft). I've also fixed the issue for the C172
and B777 specific Nasal code. These aircraft are fine now - no
performance drop even after many sim resets. But I guess many more
aircraft suffer the same problem.
Anyway, if you ever wondered why performance is so bad with FG2.0-2.6
(not sure about earlier versions) after resetting the sim or relocating
the aircraft multiple times, you now know why ;-).
cheers,
Thorsten
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Hi, On Tuesday, March 20, 2012 08:15:54 Renk Thorsten wrote: Once you understand how the scattering integrals work it's natural to compute them also from the outside of the atmosphere. Okay, now I am *really* confused. Are we trying to solve the same problem? I think so. Light scattering in the atmosphere is not part of what Earthview does at all. That is currently solved by the scattering part of the skydome shader Lauri has originally written (and which I have modified to include a haze layer and lightfields), this shader works inside the atmosphere and reasonably well outside of it (apart from a few quirks). But it should. You will get the halo around the earth by that. Thats just the same. Also if done right you just get all the altitudes in between for free correct too. Not only correct but really impressive ... Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. Well, that is probably what you call cloudsphere. These are just the scattering integrals ... Oh, the whole world model is already there. There is the spt model loader that provides this. Load w180s90-360x180.spt with fgviewer. That just happens when you call fgviewer without model (I believe, since I have a much further developed version here). You need to provide a property config that completely switches off shaders to see something useful. But well, that's all in an early state... This even works with different altitudes in between. The lod scales in between need to be improoved. But this will happen gradually I think. Apart from the fact that both somehow have to do with spaceflight, there doesn't seem to be any overlap at all?! Well, it does. :) Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and Simgear multiple format string vulnerabilities
Hi Torsten, I am quite sure Flightgear has remote exploitable bugs. Think about social attack vectors like custom sceneries, special interest aircraft models. And the multiplayer protocol, or the httpd server Running malicious code in user context is bad enough... Olaf This is low priority, because the possible code injection can only happen by the user itself and usually not over the (inter)net. And FlightGear is supposed to run in the user's context which should add some extra safety. (Never run fgfs as root or Administrator!) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG
Am 20.03.12 09:15, schrieb Renk Thorsten: Once you understand how the scattering integrals work it's natural to compute them also from the outside of the atmosphere. Okay, now I am *really* confused. Are we trying to solve the same problem? Light scattering in the atmosphere is not part of what Earthview does at all. That is currently solved by the scattering part of the skydome shader Lauri has originally written (and which I have modified to include a haze layer and lightfields), this shader works inside the atmosphere and reasonably well outside of it (apart from a few quirks). Earthview is about getting a model of the planet itself into the scene, sort of replacing the default terrain tile system. It assumes that you have already solved the atmosphere scattering problem somehow and that you want to see a pale blue marble textured globe beneath you, surrounded by a cloudsphere. Apart from the fact that both somehow have to do with spaceflight, there doesn't seem to be any overlap at all?! * Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi Thorsten I don’t know why but I get all your posting to the same topics splitted into different threads all the days. I can filter your posts of course, but can someone explain me why Thorsten’s mails to the list opens a new thread under the same title day by day ? Cheers, Yves -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
