HDTenEightyP/NetNews huggingface dataset:
From: buck@pool.info.sunyit.edu (Jesse Buckley)
Subject: Re: Setuid file
Organization: State University of New York -- Institute of Technology
Date: Tue, 10 Nov 1992 15:17:09 GMT

In article <1992Nov9.183358.12335@nas.nasa.gov> jns@ace.nas.nasa.gov (John N. Stewart) writes:
>
>In article <1d9ggiINNsfb@sequoia.ccsd.uts.EDU.AU> mgream@acacia (Matthew Gream) writes:
>>Robert Earl (chupchup@ferkel.ucsb.edu) wrote:
>>: 
>>: |    Found this on one of our systems.  Anyone know if there is any way
>>: |    this could be used to obtain root access?
>>: |    -rwsr-xr-x  1 root            0 Apr  7  1992 file
>>: 
>>: | Yes, most of the holes that work for setuid-shell scripts will work
>>: | for this file, even though it is empty.
>
>>No one yet asked what OS this was, HP-UX doesnt clear the setuid-bit on
>>an append (at least It didnt in one of its installed versions ive seen),
>>so appending a shell script to make a setuid shell is a trivial job.
>>
>>Correct me if im wrong.
>
>
>Not wrong -- SGI's don't do it either (e.g. the files setuid-bit is
>left alone). The only addition to this is that this file can only be
>appended to by root -- and if the whole point is to get root through
>this method -- well, it seems to be a catch-22.
>
>There is a simple logic -- anything that is setuid has a potential --
>it's intuitive. Sure, an empty file may not seem bad -- but there are
>potential risks.

Like a "hideing" place for suid stuff.


-- 
=) Buck (buck@sunyit.edu)
"Crime does not pay ... as well as politics."  -- A. E. Newman
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.security.misc
Subject: Re: Forging E-mail from root to get users to change passwords
Date: 6 Nov 92 15:39:20 GMT
Organization: None

ifbb657@ccwf.cc.utexas.edu (Douglas Floyd) writes:

>How common is this attack?

[attack deleted]

Quite common among novice crackers/troublemakers. It is however almost
never succesfull, very obvious and also quite annoying.

>What is the best way to prevent/slow down this form of attack?

Educate your users to pick good passwords, tell them not to tell
them to anyone, especially not to people claiming to be the
admin and needing their passwords 'for system maintenance'.

Rob
-- 
/-----------------------------------------------\	Never		   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 	 Apologize,	  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 	  Never		 /_  <
| Feel free to email me for free advice		|	   Explain.	=" `g'
From: cklaus@hotsun.nersc.gov (C. Klaus)
Newsgroups: comp.security.misc
Subject: Security Mailing Lists
Date: 8 Nov 92 00:41:51 GMT
Reply-To: cklaus@hotsun.nersc.gov (C. Klaus)
Organization: National Energy Research Supercomputer Center


I am looking for information on security mailing lists.

Are there any active mailing lists?  I know of Neil Gorsuch's mailing
list but am unable to contact him, either by phone or email.

If there is no active mailing lists, I could start one, if enough 
interest warrants it.

Thank you.
Christopher Klaus
From: paf@cyklop.nada.kth.se (Patrik Fltstrm)
Newsgroups: comp.security.misc
Subject: Re: Setuid script - is this unsecure?
Date: 5 Nov 92 07:13:54 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <1992Nov5.030530.24039@zip.eecs.umich.edu> chiner@nova.gmi.edu writes:
>rickt@bnr.co.uk (Rick Tait) writes:
>: I recently installed these shell scripts on my machine (on which I am root),
>: and I'd like to know if I'm compromising it's security. Basically, they
>: just allow the users to mount/umount/eject the floppy disk (pcfs).
>
>:     /usr/etc/mount -t pcfs /dev/fd0 /pcfs
>                            ^-o nosuid
>: 
>and some other problems...  I'll point out, that all the mount commands
>need a -o nosuid...  otherwise, anyone who can get a root shell on a disk,
>can get root on your system...

Because he is mounting the floppy as a PC-filesystem and not a BSD
filesystem (-t pcfs), there is no need for the nosuid switch.

But IF you have mounted it as a BSD filesystem, you have needed
the nosuid switch and also a switch for nodev (do not accept
devices on this device) which you don't have in SunOS, well, not
in 4.1.3 at least. 

The switch nodev and nosuid is in BSD4.4 so I still hope that users
can be able to mount there own floppies in the future. You know, even
if backups are made every hour, they can fail, and it's very
comfortable for a user to at least be able to take care of his/her own
files.

       paf
From: gr_johnson@pnl.gov (Jerry Johnson)
Newsgroups: comp.security.misc
Subject: Re: Papers on Security in Distributed Systems
Date: 10 Nov 92 19:15:18 GMT
Article-I.D.: oracle.1992Nov10.191518.18210
Organization: Pacific Northwest Laboratory
Newsreader: MS Windows WinVN

>
>I am interested in finding out how Amoeba and other distributed
>systems handle security. I am familiar with AFS, but I was 
>wondering if people can point me in the direction of some papers
>about other approaches. Thanks a lot.

"Computer & Security", Volume 10, Number 5, August, 1991, for an overview
of work being done in Europe.
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
From: uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,)
Subject: Re: Tripwire release
Originator: uri@aixproj.watson.ibm.com
Date: Fri, 13 Nov 1992 17:45:45 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

From article <BxMEuE.CwC@mentor.cc.purdue.edu>, by genek@mentor.cc.purdue.edu (Gene Kim):
>     Tripwire supports hooks for up to ten signature routines.  We
> ship it with MD5, Snefru, CRC32, CRC16, MD4, and MD2.  
> By default, Tripwire checks a file's MD5 and Snefru signature.

Good enough, I'd say (:-).

>>	b) The database of signatures is to be protected.............
> 
>     Tripwire includes a 'sigfetch' utility that simply spits out the
> signature for a given file.  A simple shell script could offer this
> functionality.  As part of the Tripwire design, we require that the
> database be immediately moved to a safe location (e.g., some read-only
> media).

Why not just prompt the user for the key, and encrypt the database?
You could have plugs for DES, IDEA, FEAL (for those not very much
security-concerned :-)...
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: GNU su doesn't restrict root access? Why?
Date: 7 Nov 92 15:37:30 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Los Tejanos SCUBA Club and Beer Joint, Austin, Tejas

In article <720912396snx@nemesys.demon.co.uk> gvm@nemesys.demon.co.uk (Granville Moore) writes:
>I'm not sure what you mean by a non-distributed system, here.  Assuming
>you mean "distributed", then if it uses NIS, or similar, then only
>the encrypted passwords are copied to the other systems, so each one
>will have exactly the same salt as it had before, and there is no
>change in vulnerabilty (from this point of view, anyway).  If the
>systems don't use NIS, then the password lists are independent, and
>your cracker has a list of 20 to work with, rather than 10.  He/she
>therefore naturally has a better chance of getting 2 salts which
>coincide.  It still doesn't help a lot, though - about a 1 in 20
>chance of getting 2 the same, and 18 different.  The chances of 3
>the same will be about 1 in 4000ish.

By "non-distributed" I mean schemes by which the password file isn't
shared by all systems through a central "distributed" database.  This
could be Andrew or NIS or ...  Each /etc/passwd is maintained on its
own.  Updating your password means going to <N> different machines
and saying "passwd".

In this situation if you have 2 machines with 10 users all sharing
root but with different account names, yes, the odds are not much
better.  But make that 10 or 20 machines and suddenly the odds get
to swing in favor of the cracker.  With 20 machines and only 1 user,
it doesn't matter - even if two of them have the same salt, you still
have to find out which SINGLE password it is.
-- 
John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org
From: probreak@matt.ksu.ksu.edu (James Michael Chacon)
Newsgroups: comp.security.misc
Subject: Re: Forging E-mail from root to get users to change passwords
Date: 5 Nov 1992 00:20:50 -0600
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

Charles Fee <CXF111@psuvm.psu.edu> writes:

>Why would a hacker (who apparently has root access) need to tell users to
>change their password?  On my system (Linux) all root has to do is wipe out
>the users' old password and then the account is free.  You could then log in
>as that user without a password and run the passwd program to change it to
>whatever the cracker feels like doing.  Similarly, couldn't this also be
>done to the root password as well?  This is all assuming that there is a
>normal /etc/passwd file.  I don't know what the story is with Yellow Pages..
>If a user has access to the passwd file, he can change the users group Id to
>0, too no?

>I'm curious as to (if the above is correct) what can be done to cut down the
>chances of such an attack..

I think you missed the point he was trying to make. Anyone with enough
expertise can forge mail that looks to the normal user as is it came from
root. I don't even have to have access to your machine, just your mail
port to do this. Then, to joe-user it appears as is root sent the mail.

James
Newsgroups: comp.security.misc
From: mrgreen@mullian.ee.mu.OZ.AU (matthew green)
Subject: Re: Setuid file
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 12 Nov 1992 02:21:47 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>jon@hill.lut.ac.uk (Jon P. Knight) writes:
>>>: |    -rwsr-xr-x  1 root            0 Apr  7  1992 file
>                                       ^
>>
>>Still, if you don't know what it is, back it up and then delete it. 
>                                      ^^^^^^^^^^

>(chuckle) he already has backed it up, an infinite number of times

Forgive me if I'm wrong..  but doesn't this imply infinite storage ?
I mean, you need to story the directory entry as well as the file
don't you?

..
Newsgroups: comp.security.misc
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: Setuid script - is this unsecure?
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Wed, 11 Nov 1992 04:59:53 GMT

Amos Shapira writes:
>A general suggestion for a programme which will do what you want would be:
>
>main (ac, av)
>	int ac;
>	char **av;
>{
>	exec ("/usr/etc/mount", av);
>}
>
>and have the object of this C programme suid root.

IMHO this is an extremely poor counterexample, since it lets the user
mount anything, with any options.  That presents its own security
risk.

Usually these special purpose mount wrappers are written with constant
arguments for exec.  For example, someone (I don't recall who) posted a
while ago:

char *env[]={"PATH=/usr/etc",(char*)0};
char *argv[]={"/usr/etc/mount","/pcfs",(char*)0};

main()
{
        setruid(getuid());
        execve("/usr/etc/mount",argv,env);
}

and a similar program for a cdrom, and two more programs for unmounting.

Brian
Newsgroups: comp.security.misc
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Setuid file
Organization: (EVIL!)
Date: Thu, 12 Nov 1992 09:11:10 GMT

valdis@black-ice.cc.vt.edu (Valdis Kletnieks) writes:

| I wonder if there's any creative applications for a mode
| 4755 /dev/null?

Besides breaking applications that expect to be able to write to it,
and don't run as root?  :-)
-- 
robert earl          |
rearl@ucsd.edu       | "I got a bottle of tequila, baby, who needs friends?"
rearl@piggy.ucsb.edu |   --Johnette Napolitano, Concrete Blonde
Newsgroups: comp.security.misc
From: adam@endor.uucp (Adam Shostack)
Subject: Re: Setuid script - is this unsecure?
Organization: Aiken Computation Lab, Harvard University
Date: Thu, 5 Nov 1992 19:05:32 GMT

In article <1d6fdiINNf5q@bnsgd245.bnr.co.uk> rickt@bnr.co.uk (Rick Tait) writes:
>I recently installed these shell scripts on my machine (on which I am root),
>and I'd like to know if I'm compromising it's security. Basically, they
>just allow the users to mount/umount/eject the floppy disk (pcfs).

>-rwSr-xr-x  1 root     staff         368 Oct 11 11:20 in*
>-rwSr-xr-x  1 root     staff          42 Oct 23 15:05 out*

Why not use sudo to allow mounting of floppy disks?  It avoids the
race condition, and is easily configured to do what you want.

You can get it from csn.org:/pub/sudo

Adam



Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all because of elections.  How true that is.
Xref: sparky comp.security.misc:1656 comp.unix.wizards:4550
From: yedidya@bimacs.BITNET (Yedidya Israel)
Newsgroups: comp.security.misc,comp.unix.wizards
Subject: Re: Setuid script - is this unsecure?
Date: 5 Nov 92 19:10:55 GMT
Organization: Math department, Bar-Ilan University, Ramat-Gan, ISRAEL

In article <1d6fdiINNf5q@bnsgd245.bnr.co.uk> rickt@bnr.co.uk (Rick Tait) writes:
>I recently installed these shell scripts on my machine (on which I am root),
>and I'd like to know if I'm compromising it's security. Basically, they
>just allow the users to mount/umount/eject the floppy disk (pcfs).

Did anyone tried to solve this old problem with automounter ?
Something like (with amd)

pcfs            host==sunblast;type:=program;\
                mount:="/usr/etc/mount_pcfs mount_pcfs /dev/fd0 /amd.direct/pcfs nosuid";\
                unmount:="/etc/umount umount /dev/fd0"

I get the following message:

Nov  5 21:09:22 sunblast amd[126]/error: /amd.direct/pcfs: mount
(afs_cont): Not owner

--
Israel Yedidya,         Phone:  972-3-5318682 or 972-3-5318407/8
System Administrator,   Fax:    972-3-5353325
Math & CS Department,   Email:  yedidya@bimacs.cs.biu.ac.il
Bar-Ilan University,    Bitnet: yedidya@bimacs
Ramat-Gan, ISRAEL.      Uucp:   ...!uunet!pucc.princeton.edu!bimacs!yedidya
If someone proves there is no God, I'll stop being religious!
Newsgroups: comp.security.misc
From: seb@LNS62.TN.CORNELL.EDU
Subject: network access policy documents?
Nntp-Posting-User: seb1@cornell.edu
Reply-To: SEB@lns62.tn.cornell.edu
Organization: Wilson Lab, Cornell U., Ithaca, NY, 14853
Date: Fri, 13 Nov 1992 16:35:43 GMT

Gentle folk,

It is my understanding that there is a general policy to discourage
the connection of network devices like terminal servers which
do not include some form of login authentication or other means
of accountability.

Can anyone point me to any documents which formalize this restriction? 
While the need for such a policy is painfully clear to me, 
it is not so obvious to others.

Please send explicit references to one of my e'mail addresses below.
I'll post a summary.

Thanks,

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: +1-607-255-0688 
Laboratory of Nuclear Studies        FAX: +1-607-255-8062
Wilson Synchrotron Lab            BITNET: SEB@CRNLNS
Judd Falls & Dryden Road        Internet: SEB@LNS61.TN.CORNELL.EDU
Ithaca, NY, USA 14853-8001   HEPnet/SPAN: LNS61::SEB = 44283::SEB
Xref: sparky comp.security.misc:1734 alt.security:4802 comp.unix.admin:6170
From: mccurley@cs.sandia.gov (Kevin McCurley)
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
Subject: Re: Tripwire release
Date: 13 Nov 92 00:47:08 GMT
Organization: Sandia National Laboratories, Albuquerque, NM

uri@watson.ibm.com (Uri Blumenthal) writes:
>    Tripwire supports hooks for up to ten signature routines.  We
>ship it with MD5, Snefru, CRC32, CRC16, MD4, and MD2.  Although
>the CRC routines are not "signatures" in the cryptographic sense,
>they are nice to have since they are considerably faster than the
>more secure algorithms -- which are (hopefully) one-way hash
>functions.

I stated earlier that NONE of these, including MD5, Snefru, and MD4,
are signatures in the cryptographic sense.  A true signature would
require something like RSA or DSA layered on a one-way hash function
like MD5 or SHA.  This would not significantly impact the speed, since
RSA on my Sparc would add less than .01 seconds, whereas MD5 runs at
about a megabyte per second.  Hence as soon as the file is bigger than
10K, the hash will take longer than the signature.  DSA verification
will take considerably longer, but I have an implementation that does
the verification in less than .3 seconds - still acceptable for many
applications.  If this is too slow for checking 100 files on a UNIX
system, then you can apply the hash to a large subset of the files
before finishing with the signature.

Kevin McCurley
Sandia National Laboratories
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.security.misc
Subject: Re: Proactive password checkers
Date: 7 Nov 1992 04:39:56 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Nov6.202148.1587@cs.sandia.gov> wllarso@sandia.gov (William L Larson) writes:
>How long does it take to proactivly check passwords using npasswd,
>passwd+, or Larry Wall's passwd Perl script.

We use npasswd and the overhead is imperceptible on a Sparcstation.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
From: vince@ghost.dsi.unimi.it (David Vincenzetti)
Subject: Re: Tripwire release
Organization: Computer Science Dep. - Milan University
Date: Fri, 6 Nov 1992 16:11:25 GMT

In <LIMES.92Nov5142000@ouroborous.eng.sun.com> limes@ouroborous.eng.sun.com (Greg Limes) writes:

>If I can make that backward calculation either
>directly or by trial-and-error in a reasonable time, then your
>signature protection system is no protection.

I strongly agree. That's why I wrote my ATP program. A version
portable to BSD will be ready soon. Anyway ATP is very like tripwire
but is protects its database with DES/CBC. I gonna release it to
the net and to ftp@ghost.dsi.unimi.it:/pub/security as soon as I finish.

Regards,
David
-- 
David Vincenzetti := {System, Security} Administrator
  Department of CS,             Email : vince@ghost.dsi.unimi.it
  via Comelico 41,              Voice : ++39 2 55006 392
 I-20133 Milan, ITALY             Fax : ++39 2 55006 373
Newsgroups: comp.security.misc
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: NEED GENERAL INFORMATION ON WIRELESS LANS
Organization: AT&T Bell Labs Business Special Services.
Date: Fri, 6 Nov 1992 04:15:48 GMT

In article <jenn_b.5@aci_1.aci.ns.ca> jenn_b@aci_1.aci.ns.ca (JENNIFER BAKER) writes:
   What are some of the security measures to consider when dealing with 
   WIRELESS LANS.

Well, the usual questions concern issues like 
	- how sensitive is your data?
	- what kinds of threats are you worried about?
		(including, e.g., who's listening, how good are they, 
		loss-of-service?  jamming?  interference?)
	- how far are you broadcasting?
	- how near are your neighbors
	- how fast is your data rate?
	- what's on the LAN?  email only?  telnet with passwords?  NFS?

If you want a product plug, AT&T / NCR's WaveLAN product uses
spread-spectrum radio, which is hard to intercept and relatively
tolerant of noise and other LANs in the same area,
and offers an optional DES encryption chip (US only, I assume)
to provide much better security.  I forget the bit rate,
but it's about 2 mb/s, and the PC plugin cards emulate the standard 
PC Ethernet cards, so it's protocol-transparent, just a bit slower.
I think the range is around 200-300 meters for broadcast and 
10 km for line-of-sight with a directional antenna.
Email me if you want more details; I'll try to find some product literature.
--
#				Pray for peace;      Bill
# Bill Stewart 908-949-0705 wcs@anchor.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Nov 12 - Anniversary of Indonesian massacre in East Timor, 1991
# Indonesia first invaded in 1975, and about 1/3 of the people have been killed.
From: kludge@grissom.larc.nasa.gov (Scott Dorsey)
Newsgroups: comp.security.misc
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Date: 13 Nov 1992 17:28:58 GMT
Organization: NASA Langley Research Center and Reptile Farm
NNTP-Posting-Host: grissom.larc.nasa.gov

In article <1992Nov12.142251.9131@hubcap.clemson.edu> stehman%citron.cs.clemson.edu@hubcap.clemson.edu writes:
>From article <1992Nov12.084549.5128@unix.brighton.ac.uk>, by ddv@unix.brighton.ac.uk (Domenico De Vitto):
>> Any org. that has a _root_ password in _a_ dictionary gets all it deserves.
>
>Would you like to require people to read c.s.m for a couple of months before
>they're allowed to purchase a computer?

Yes.
--scott
From: pc123@cus.cam.ac.uk (Pete Chown)
Newsgroups: comp.security.misc
Subject: Re: Setuid file
Date: 8 Nov 92 19:52:46 GMT
Organization: U of Cambridge, England

In article <1992Nov7.203923.522@news.Hawaii.Edu> newsham@wiliki.eng.hawaii.edu (Timothy Newsham) writes:
>
>I just made an empty file with +x perms and typed in its
>name at the shell prompt.  It apparently tried to execute it
>and for some reason sourced my .cshrc.  This is on an older
>HPUX system.  I didnt however set it suid since I am a non-priveledged
>user so I cant tell you if it would work as suid.  (I think i
>remember that hpux wouldnt run shell scripts with out the '#!' in
>them as suid, maybe just a local patch?)

Most shells try to run scripts without a #! at the start by passing
the name as an argument to sh or csh.  This is entirely a shell
feature and has nothing to do with the kernel.  Because the shell is
non-privileged, the resulting process that sources your .cshrc will
also be.

So this is one case where setuid scripts are harmless (if also
ineffectual since even the legitimate code won't run with privilege).
-- 
---------------------------------------------+ "A tight hat can be stretched.
Pete Chown, pc123@phx.cam.ac.uk (Internet)   |  First damp the head with steam
            pc123@uk.ac.cam.phx (Janet :-)  -+  from a boiling kettle."
From: rubin@barnone.citi.umich.edu (Aviel David Rubin)
Newsgroups: comp.security.misc
Subject: Papers on Security in Distributed Systems
Date: 9 Nov 1992 14:25:06 GMT
Organization: University of Michigan
Distribution: world
Reply-To: rubin@barnone.citi.umich.edu (Aviel David Rubin)
NNTP-Posting-Host: barnone.citi.umich.edu

I am interested in finding out how Amoeba and other distributed
systems handle security. I am familiar with AFS, but I was 
wondering if people can point me in the direction of some papers
about other approaches. Thanks a lot.


Newsgroups: comp.security.misc
From: cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi)
Subject: Re: Window watching programs
Organization: Computer Science Dep. - Milan University
Date: Mon, 9 Nov 1992 08:40:48 GMT
Distribution: na

paulc@plume.mit.edu (Paul Cloke) writes:

>It is interesting to note that the window watching program
>I have a copy of does not work if you change your xterm to
>run in "Secure Keyboard" mode (Press control and left mouse
>in an xterm and select the top item). I always use this mode
>when typing in passwords, although I'm not sure whether it could
>be circumvented by a knowledgable hacker.

>Paul Cloke
otherwise you can use sxterm, which makes it by default ..

Massimo
-- 
 -- Massimo Cotrozzi  Computer Science Dept. Milan Italy
            cotrozzi@ghost.dsi.unimi.it  +39-2-27201253
 #include     <std/disclaimer.h>
Organization: Freshman, CIT general, Carnegie Mellon, Pittsburgh, PA