Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Yandex, Sogou, DotBot

Members: 0
Guests: 7
Stats
Files
Topics
Posts
Members
Newest Member
481
3,734
19,366
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » AFKMud Support & Development » Possible bug in interface code
Forum Rules | Mark all | Recent Posts

Possible bug in interface code
< Newer Topic :: Older Topic > buffer overrun

Pages:<< prev 1 next >>
Post is unread #1 Sep 3, 2003, 8:50 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

In my quest to eradicate non-length-limited versions of strcpy and friends, I found a probably buffer overrun bug in iafk.c (and also the other interface files).
In the afk_who() routine, the variable stats is declared to be a 20 byte string. However, as we fill in the various status flags, we add far more than 20 bytes due to all the color codes. I believe this was intended to be a 20 "character position" buffer so that it takes 20 columns in the display, but needs to be more than 20 bytes long since the addition of color.
When I replaced the various strcat's with length limited ones, I found it was being truncated. Since this isn't dynamically allocated, Electric Fence can't catch it, and presumably the unlimited strcat just stomps on whatever is next in memory (most like invis_str[]).
I'd suggest switching it to an MIL (MAX_INPUT_LENGTH) buffer size. I hope to provide Samson with a patch soon to nail down many of the potentials like this, but testing takes time, and I figured this might actually stop a crash or two somewhere out there.
       
Post is unread #2 Sep 4, 2003, 8:54 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Nice catch, hadn't even really noticed that. Looks like it's also a viable fix for the i3who stuff as well since that was also a mere 20 bytes. Makes me wonder just how bad off things are at this point :P
       
Post is unread #3 Sep 10, 2003, 10:17 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

BTW, I'm obviously still interested in the buffer overflow findings, but I wonder if some of what you might have been chasing were related to the I3 problems? Perhaps you might consider checking against 1.56a instead now?
       
Pages:<< prev 1 next >>