Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Yahoo!, DotBot

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Exploit in do_trajectory
Forum Rules | Mark all | Recent Posts

Exploit in do_trajectory
< Newer Topic :: Older Topic > Possible exploit?

Pages:<< prev 1, 2 next >>
Post is unread #1 Dec 12, 2006, 5:43 pm
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

Try this one. Go into space and type "course inf inf inf", and after moving a bit, your coordinates become nan nan nan, and you can now land on anything in that system from whatever spot you're at. A player found this one, and I applied this fix for it..

Find, in space.c, do_trajectory:
   argument = one_argument( argument, arg2 );
   argument = one_argument( argument, arg3 );

   vx = atof( arg2 );
   vy = atof( arg3 );
   vz = atof( argument );      

   if( vx == ship->vx && vy == ship->vy && vz == ship->vz )
   {                        
      ch_printf( ch, "&B[&CShip Computer&B] &WThe ship is already at &R%.0f %.0f %.0f &W!", vx, vy, vz );
   }  


Change it to look like this:
   vx = atoi( arg2 );
   vy = atoi( arg3 );
   vz = atoi( argument );      


Change the atof to atoi. When letters are used in course, this makes them 0, but still lets you use negative and positive numbers. I'm not sure why course uses atof when calculate uses atoi. In do_trajectory, those three calls to atof were the only three in my code. If I'm wrong about changing this, feel free to tell me. Thanks in advance.
       
Post is unread #2 Dec 25, 2006, 8:08 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

ATOF(3) Linux Programmer's Manual ATOF(3)

NAME
atof - convert a string to a double

SYNOPSIS
#include <stdlib.h>

double atof(const char *nptr);

DESCRIPTION
The atof() function converts the initial portion of the string pointed to by nptr to double. The
behaviour is the same as

strtod(nptr, (char **)NULL);

except that atof() does not detect errors.

RETURN VALUE
The converted value.


My guess, not knowing that much about the SWR space system, is that the choice to use atof() was deliberate since the values being worked with are floating point decimal numbers. The proper fix for your problem would be to verify the input as being numeric rather than trying to fudge it by switching to atoi() which will cause a loss of precision.
       
Post is unread #3 Jan 29, 2008, 12:51 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Just in case something other than trajectory causes this problem, I fixed it in move_ships() instead of adding a whole bunch of checks elsewhere. I added this:

if ( ship->hx == atof("inf") )
ship->hx = 0;
if ( ship->hy == atof("inf") )
ship->hy = 0;
if ( ship->hz == atof("inf") )
ship->hz = 0;

Just before line 409:

change = sqrt( ship->hx*ship->hx + ship->hy*ship->hy + ship->hz*ship->hz );

Adding is_number checks for the arguments will fix do_trajectory. Additionally, for the above, finding out the bit value for 'inf' and replacing the atoi calls with it would be more efficient.

DV
       
Post is unread #4 Jan 29, 2008, 12:57 pm
Go to the top of the page
Go to the bottom of the page

Darrik
Fledgling
GroupMembers
Posts20
JoinedJan 29, 2008


Including math.h gives you the following defines:

INFINITY

NAN

The fix now becomes

if ( ship->hx == INFINITY )

etc.

Adding checks for NAN and returning the ship to lastdoc if true prevents that issue should you ever mess up a space function ( I had that problem a lot when I was doing SWRIP's space code ).

DV
       
Post is unread #5 Feb 14, 2008, 4:52 am   Last edited Feb 14, 2008, 4:53 am by Caius
Go to the top of the page
Go to the bottom of the page

Caius
Magician
GroupMembers
Posts132
JoinedJan 29, 2006

"nan" means "not a number" and is used in mathematics. You get it when dividing by zero in float and double calculations. Unlike for ints, divide by zero doesn't crash when used on floats.

And I agree that checking it, rather than converting to integers, is best in the name of precision.
       
Post is unread #6 Feb 17, 2008, 8:15 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Ok, so just to get this straight, can someone post what the proper fix for this should be?
       
Post is unread #7 Feb 18, 2008, 2:40 pm
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

I'd go with what I orginally posted. What they suggested just covers up the error if it occurs. I've been using my fix for months and it hasn't caused any problems, and every other point in the code uses the atoi, so atof was probably a typo. And if atof deals with decimal values, what is it's purpose in calculate anyway when all numbers are real numbers?
       
Post is unread #8 Feb 19, 2008, 1:13 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I think you mean whole number, not real number, no? Real numbers can have decimal points so if you want to use those, you must use atof, not atoi.

If the problem here is just to avoid the nan and inf cases, those should be handled using the constants Darrik provided. (That's part of the reason why they exist, after all.) It's not a "cover-up" -- it's handling a perfectly legitimate input value for atof.

In the end, the question has an extremely simple answer:

- if coordinates can have decimal points, you must use atof and deal with validating input (to exclude cases like 'inf' and 'nan' as inputs)
- if coordinates don't have decimal points, then don't bother with atof and use atoi instead.
       
Post is unread #9 Feb 19, 2008, 8:15 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Since I'm not familiar with the space code in SWR I'd prefer to defer to someone who does who can answer for sure that the coordinates don't make use of decimal values. I don't want a bugfix being responsible for a loss of necessary precision in the calculations.
       
Post is unread #10 Feb 19, 2008, 10:18 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

The coordinates seem to use decimal points while moving things around, so that probably has to stay; I think however the question here is whether users need to specify decimal points in the do_trajectory command. Banner seems to be saying that users on his MUD don't need that precision.
       
Post is unread #11 Feb 20, 2008, 6:38 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

On what few SWRs I've played it's always something like:
Trajectory 3500 4000 2300
or
course 3000 3000 3000

But I've never tried putting in decimal numbers...
       
Post is unread #12 Feb 20, 2008, 4:03 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Kayle said:

On what few SWRs I've played [...] But I've never tried putting in decimal numbers...

Then, clearly, it's time for you to log back into one of them and try it, eh? :tongue:
       
Post is unread #13 Feb 20, 2008, 8:56 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Banner's MUD may not require the use of decimals, but the FUSS package isn't just for him :)

A fix would need to be more general and preserve the intent if decimal coordinates were intentionally offered.
       
Post is unread #14 Feb 21, 2008, 9:04 am
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

Well, I am familiar with the space code, having used and played in it for a long time. I also tried to use decimals on your SWR 1.2 FUSS - didn't work. And from experience, decimals are -not- needed. So atoi is a better use.

ALSO! Darrik's "fix" wants you to set the ship's back to 0 0 0 if it encoutners a NAN. Now, what is located at 0 0 0? The sun, in most space systems. So if we put the ship back at 0 0 0, we put the player's ship in the sun, and kill the player.
       
Post is unread #15 Feb 21, 2008, 9:15 am
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

Speaking from experience a Sun Run isn't fun. Especially if I'm in the other end of the system from the sun. >.>
       
Post is unread #16 Feb 21, 2008, 9:59 am   Last edited Feb 21, 2008, 10:00 am by Banner
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

Yes, I know, that's why I addressed the fix. It would be a bit more of a problem to put a player in the sun than to remove the exploit I found.
       
Post is unread #17 Feb 21, 2008, 12:32 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

The proper thing to do would be to validate the input in the command for inf/nan and report an error there instead of putting the player to 0,0,0.

Banner, your fix also puts people to 0,0,0 if they use inf in their command, you said so yourself:
Banner said:

When letters are used in course, this makes them 0

So I'm not sure why you say your fix has different behavior in that regard. :-)

Again the proper fix here, if one wants to avoid bogus input values, is to simply check those values and report an error to the player if need be...
       
Post is unread #18 Feb 21, 2008, 5:12 pm
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

Oh, I apologize. hx, hy, hz ect. set the course. vx, vy, vz are the current location of the ship in space. So setting the h one's to 0 just sets it's destination to 0, not the current location, so that fix would be acceptable, I apologize.
       
Post is unread #19 Feb 21, 2008, 5:27 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Hmm... Wouldn't it be better if the variables had better names than just "vx" and "hx", like, say, "posX" and "destX"? :thinking:
       
Post is unread #20 Feb 21, 2008, 6:34 pm
Go to the top of the page
Go to the bottom of the page

Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005

Lol, that's a whole other topic. SWR 1.0 team is the one that did it like that.
       
Pages:<< prev 1, 2 next >>