Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
auth_update crash
Dec 23, 2017, 10:15 pm
By Remcon
check_tumble
Dec 18, 2017, 7:21 pm
By Remcon
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
LoP 1.46
Author: Remcon
Submitted by: Remcon
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
Users Online
CommonCrawl, Google, Bing, Yandex

Members: 0
Guests: 6
Stats
Files
Topics
Posts
Members
Newest Member
478
3,708
19,242
612
Jacki72H
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,639
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,639
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 >>