Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread botman
 Bugtraq (a security related mailing list) just posted 3 advisories
 concerning Half-Life (HLTV, ClanMod, Adminmod). I highly recommend to any
 coder and/or sysadmin to check these out (I'm not going to reproduce them
 here, bugtraq has an excellent archive). Although there's no fix available
 yet, you should at least know about the possible dangers.

 Just to clearify things: I'm in NO way related to those who found the
 vulnerabilities, I'm just telling you that these exist so you know what
 you'll have to deal with sooner or later.

Here's the URL's for those of you that are not bugtraq savy...

http://online.securityfocus.com/archive/1/306122/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306120/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306117/2003-01-07/2003-01-13/0

The AdminMOD and ClanMod exploits REQUIRE knowledge of the rcon password.

Jeffrey botman Broome

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Sebastian Steinlechner
Hallo,

Friday, January 10, 2003, 20:44,
botman [EMAIL PROTECTED] wrote:

Thanks botman, I was unsure whether it would be a good idea to post the
urls here, so you decided it for me...

 http://online.securityfocus.com/archive/1/306120/2003-01-07/2003-01-13/0

Actually, this advisory isn't researched to the end. The main problem lies
in cl_dll's text_message.cpp. Looking at CHudTextMessage::MsgFunc_TextMsg()
it's clear to see that there are MANY potential buffer overflows. e.g.,
READ_STRING is able to return a char array as long as 2048 chars, however,
MsgFunc_TextMsg() does only declare an array of 128 chars, where the string
returned by READ_STRING is copied into via strcpy without any checks.

--
Sebastian Steinlechner
- mailto:[EMAIL PROTECTED]
- www.resourcecode.de

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Creating a persistant statistic database?

2003-01-10 Thread jc
i really hope they are still working on it; i just added the test version to
my mod Valve if u r listening... plz finsih VPP... please!

jc

- Original Message -
From: JR [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 10, 2003 2:31 AM
Subject: Re: [hlcoders] Creating a persistant statistic database?


 Is Valve still working on this? Has the backend been written?

 - Original Message -
 
  Check out  the Valve Player Persistence API , which shows you how to do
 this type
  of DB stuff. I can't remember the URL, but there is a mirror of the d/l
 here
  http://www.edgefiles.com/index.php/file?id=590
 
  Jeff Codiac Fearn
  -
  Lead Coder, Web Master, Server Administrator for SWARM
  http://swarm.edgegaming.com
  -
 
 
  ___
  To unsubscribe, edit your list preferences, or view the list archives,
 please visit:
  http://list.valvesoftware.com/mailman/listinfo/hlcoders
 
 

 ___
 To unsubscribe, edit your list preferences, or view the list archives,
please visit:
 http://list.valvesoftware.com/mailman/listinfo/hlcoders



___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Pat Magnan
At 01:44 PM 1/10/2003 -0600, you wrote:

 Bugtraq (a security related mailing list) just posted 3 advisories
 concerning Half-Life (HLTV, ClanMod, Adminmod). I highly recommend to any
 coder and/or sysadmin to check these out (I'm not going to reproduce them
 here, bugtraq has an excellent archive). Although there's no fix available
 yet, you should at least know about the possible dangers.

 Just to clearify things: I'm in NO way related to those who found the
 vulnerabilities, I'm just telling you that these exist so you know what
 you'll have to deal with sooner or later.

Here's the URL's for those of you that are not bugtraq savy...

http://online.securityfocus.com/archive/1/306122/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306120/2003-01-07/2003-01-13/0

http://online.securityfocus.com/archive/1/306117/2003-01-07/2003-01-13/0

The AdminMOD and ClanMod exploits REQUIRE knowledge of the rcon password.


In theory the rcon password could be sniffed, as I believe they're plain
text? :(

I'm also concerned after reviewing the site, I'm not sure if their hat
colour is black, white, or maybe 'grey'.

There are several articles on 'attacking MySQL servers' or various other
things. There is a disclaimer about study purposes, etc.. for what's it's
worth.

The good news is that the potential seems limited for those not running
their servers as root, in the case of the clanmod one.



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Jussi Kivilinna
On Fri, 10 Jan 2003, Pat Magnan wrote:

 The good news is that the potential seems limited for those not running
 their servers as root, in the case of the clanmod one.


We are getting fixed clanmod binaries out really soon.

.-
 Jussi Kivilinna [EMAIL PROTECTED]
 http://jussikivilinna.cjb.net/


___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Cortex
Sebastian Steinlechner wrote:
 Actually, this advisory isn't researched to the end. The main problem
 lies in cl_dll's text_message.cpp. Looking at
 CHudTextMessage::MsgFunc_TextMsg() it's clear to see that there are
 MANY potential buffer overflows. e.g., READ_STRING is able to return
 a char array as long as 2048 chars, however, MsgFunc_TextMsg() does
 only declare an array of 128 chars, where the string returned by
 READ_STRING is copied into via strcpy without any checks.

And ? What can be done if a buffer overflows ? It's perhaps a basic
question, but I really don't know anything about *hacking*. And I'm sure I'm
not the only one there :)

Well, explain it only if it can't give enough info about making hack for HL
!

  - Cortex : HL ALBATOR coder  mapper
  - [EMAIL PROTECTED]  ICQ : 71548738


___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Pat Magnan
I'll try, i've just been reading my first book about how this works.

I'm a somewhat junior programmer so my understanding is somewhat lacking. I
believe that it is possible because of the way things are represented in
memory, when you're taking in input from a user, so something like this:

void somefunc(char * someNastyUserspaceStrings)
{
 char mybuf[32] = someNastyUserspaceStrings;
 ...
}

The attacker sends a longer than 32 byte string into that 'untrusted user
input',  putting code which overwrites the return address of the function
that should be in memory at or near? the end of the buffer, with the
address of a function call of your choice. Someone else can probably
explain that part better.

So rather than executing what you've specified when the function returns,
it proceeds to the attacker's nasty code.

If hlds_l is running as root, that can be pretty bad. Because the attacker
can setup any arbitrary code to run, they could say start a shell on port
17000, change root's password to what they want, connect to it, and be root
on your system.

There's many reasons why services that are known to run as root have been
attacked over the years, if the service runs as root and i can overflow a
buffer, I become root (hence the term 'rooted') with the right script.



At 09:26 PM 1/10/2003 +0100, you wrote:

Sebastian Steinlechner wrote:
 Actually, this advisory isn't researched to the end. The main problem
 lies in cl_dll's text_message.cpp. Looking at
 CHudTextMessage::MsgFunc_TextMsg() it's clear to see that there are
 MANY potential buffer overflows. e.g., READ_STRING is able to return
 a char array as long as 2048 chars, however, MsgFunc_TextMsg() does
 only declare an array of 128 chars, where the string returned by
 READ_STRING is copied into via strcpy without any checks.

And ? What can be done if a buffer overflows ? It's perhaps a basic
question, but I really don't know anything about *hacking*. And I'm sure I'm
not the only one there :)

Well, explain it only if it can't give enough info about making hack for HL
!

  - Cortex : HL ALBATOR coder  mapper
  - [EMAIL PROTECTED]  ICQ : 71548738


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders


Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders




Re: [hlcoders] Bugtraq: hl exploits

2003-01-10 Thread Pat Magnan
At 09:26 PM 1/10/2003 +0100, you wrote:

Well, explain it only if it can't give enough info about making hack for HL


Sorry, one more point. If we as programmers don't understand what hackers
do, how can we write secure code? :D. We should never be afraid to
understand how they work, such information doesn't necessarily lead to
cheats/hacks, it allows us collectively to eliminate them from our code.
It's certain they're (the black hats) educating each other, it's only fair
that we try to educate ourselves being the white hats we are (personally,
I'm more of a redhat) :).

Even with a cursory understanding that I'm currently getting for these
issues (pick up 'Writing Secure Code' from Microsoft Press -- it's not bad,
and the issues they talk about aren't totally Windows specific), i'm at
least taking a step that too many programmers tend to put off until later
-- thinking about writing the code securely from the get go. You don't have
to be a genius to not make a buffer overflow, you just have to think about
them when dealing with user input, and have a few 'standard tricks' in your
arsenal to avoid them. ;).

/me gets off soapbox



Pat 'sluggo' Magnan
Tour of Duty mod
http://www.tourofdutymod.com

___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders