December 2003 - cypherpunks-legacy

re: CERT funding
by Mark Hittinger 17 Dec '03

17 Dec '03

>From: Anonymous <nowhere(a)bsu-cs.bsu.edu> >This question has come up a couple of times lately, and nobody seems to >be talking. >Does anyone know the budget size and sources for CERT? Is CERT >'officially' part of the government or do they operate independently? >And could a FOIA request yield results, do you think? I saw a message on this topic a couple of days ago where the poster speculated about NSA funding for CERT. I posted the following reply to the cypherpunks list then but I did not see it echoed to the list. Maybe the work being done for the ratings hoo-ha lost some of the postings. Anyhow here it goes again - my apologies if you've seen this already. Don't get too worried about CERT and its budget. I interviewed there - oh - around 18 months ago. This was prior to the sniffer fiascos and the sendmail-bug-of-the-week deluge. CERT had a section of the "Institute for Software Engineering" building which is a very nice building next to CMU. The CERT offices were kind of crowded and there were some partitions. Most of the staff had their own office, however. I noted which ones had window offices and stored it away. There were three! :-) The staff seemed to be all comp-sci grad student types. The main guy was your typical visionary professor type. Before I spoke with him he was interrupted by a call from someone at DARPA about their funding. I am certain that he was having trouble convincing his funders that the problems were growing and that CERT's budget should expand. I got the impression that continued funding of CERT was not a done deal and that even keeping the current level of funding was uncertain. My point - the funding was not substantial and it was not "reliable" funding. Their hardware was fairly recent but I did see a lot of "old soldier" type computer equipment still in service. There was mostly SUN, some DEC R4000 stuff, and maybe a microvaxII. Most definetly not NSA funded. It is funded by DARPA/USAF just like most old arpanet activity was. As I interviewed with nearly all of the staff I can say they are all most definetly comp-sci grad student types. Probably all working on MS or PHD over at CMU. I was intrigued by the types of questions that they asked me about. I was asked more questions about software engineering issues than about security issues. I got the impression that most of the staff had only a peripheral understanding of the technical weaknesses in the current installed base. I know that structured programming, relational databases, case tools, and AI are important but are they important in an OS security framework? (shrug) I asked them what got CERT started and they told me it was kind of put together informally after the morris internet worm holiday. I was surprised that they only seemed truely interested in SUN issues. I did not get the impression they were concerned about PC's on the net, VMS systems, or other platforms. Perhaps they all wanted to go to work for SUN later? :-) :-) Clearly other platforms can serve as vehicles for intrusion, and clearly they needed to be interested in anything with an ethernet plug on it. I was surprised by this - I still am. I was also surprised to find out that there were several organizations other than CERT executing the same functions for each government agency. I learned that there was one for the navy, the dod, the cia, and probably even the coast guard! :-) I wondered aloud about how much information these groups shared and I got the impression that the other groups might not have trusted CERT too much with good information. In other words there is probably a group that you guys should be worried about because they are deeper in the black and they don't trust the CERT guys either! :-) :-) I was surprised to see the level of calls that CERT was getting. I saw an endless stream of E-mail and phone calls. One staff member told me that they were averaging around 1400 E-mail messages a day!! Holy shit! Remember this was before sendmail/sniffer! It must be exploding "elm" up there right now. :-) :-) CMU had very good fringe benefits by the way. I had a real good time and the CERT staff treated me very well. The CMU campus was clean and pleasing to the eye. Just to show they are real computer people they took me to lunch at pizza hut. It was the first time I'd ever seen anybody use one of those "the club" things on their car wheel. :-) :-) Anyway I didn't get the position. On the one hand I thought it would be pretty neat but on the other hand I knew the problems they were going to have to deal with were only going to grow like crazy. I thought something big would happen but I didn't expect the hilarious level that the sendmail and /dev/nit problems would reach. The CERT guys have my sympathy. Maybe it was just my good luck working to bail me out again? I didn't get the impression that they were that up to speed on what could be done to either attack or defend OS security. I am sure they are getting a fast education in that. I am also certain they are getting a fast education in the politics of blame. I see a lot of people really hammering them for surpressing information or ignoring problems. I think we need to realize that they are a small staff and the internet is a mighty big ranch. Clearly they are overwhelmed. I am also certain that they are learning the politics of getting vendors off their butts to fix things. GROAN!! :-) :-) To top it all off they have to also specialize in the politics of getting continued funding. What a thankless task, so utterly unappreciated by the reckless drivers on the superhighway. :-) :-) I think we need a be kind to CERT-person-with-beeper-week where all hackers voluntarily stop what they are playing with. This week could begin the day prior to christmas eve and last until January 2. --------- I'd like a 250 Mhz 128 bit hybrid processor with 64 meg of 8 way interleaved memory, a 10 megabyte per second i/o channel, two 3 gig hard disks, two dat drives with compression, and a large diet coke. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiz4FWMAAAEEALBCb7HZS7V4gbsp9yJ7Yty49jQ9wcgRhkLjNNgdyJbrJZCq 5/sv4Ljy/4AhVhjlJyZS8L3owS8l0ClZVzWw4/kO3KN7MPz4YPPR7+qIlPQVM0yv gWpJ43EZZ8b8cvAkE9HATCKWktY2ReRSX5DLnScDH/n5jivw+MD/UO8fURCVAAUR tCBNYXJrIEhpdHRpbmdlciA8YnVnc0BuZXRzeXMuY29tPg== =VbKi -----END PGP PUBLIC KEY BLOCK-----

1 0

Supreme Court on Anonymity
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- - From today's (February 23) New York Times (quoted without permission): By Linda Greenhouse WASHINGTON, Feb. 22: The Supreme Court agreed today to decide whether states can ban the distribution of anonymous campaign literature. The case is an appeal by an Ohio woman who was fined under the state's election law for distributing leaflets, signed only by "concerned parents and taxpayers," urging the defeat of a local tax referendum. At stake is the constitutional balance between the free speech rights protected under the First Amendment and a state's interest in guarding against election fraud. Half of the states, including Connecticut and New Jersey, have laws similar to Ohio's. While the Supreme court has never discussed anonymous leaflets in the context of election laws, it did rule in 1960 that the organizers of a consumer boycott directed at racially biased mechants could not be required to identify themselves on their literature. Historically, persecuted or unpopular groups have "been able to criticized oppressive practices and laws either anonymously or not at all," the court said in that decision, Talley v. California. On the other hand, the Court has granted the states more latitude to restrict speech as part of election regulations, recently upholding bans on write-in voting and on electioneering near polling places. The Ohio Supreme Court, in ruling last year to uphold the ban on anonymous leaflets, said the state law was consistent with the Supreme Court's view that speech could be limited to deter voter fraud. Interesting, eh? faust's dog -----BEGIN PGP SIGNATURE----- Version: 2.3a iQBpAgUBLWxKQIp26HwU0zr9AQGxfQKZAec+cnCSOHjLSsQjJxQbd1u5IRNw3/Jr H3IltqoypEPRa1H7LYoVQ7RNmiGrcL2730JmABCS3C56k5x/T/IZBeyFtCGussso vscFrB2NGxRCH8Ho =UPD9 -----END PGP SIGNATURE-----

1 0

Re: STEALTH OCEANS
by Matt Thomlinson 17 Dec '03

17 Dec '03

Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> writes: >> might work, except for the fact that fragmentation _does_ go on, and when >> you were to write files to the drive (heck, I do every time I start up >> windows and write a huge temp swapfile) you're going to be playing >> roulette with your data. >This problem is solved by simply using a utility that writes directly to the >disk (exactly in the specified sectors, in the specified order), instead >of letting DOS fragment your disk. I've been talking to Sergey behind the scenes, and I think I understand what our miscommunication was: he is proposing this type of technique ONLY for removable-type media, e.g. floppies. To store this type of data on your harddrive would be to dedicate your harddrive to stego. This was my argument all along; what we failed to connect on was the fact that only floppies are involved. With floppies, every write *can* be controlled and the data would be relatively safe (and obscure, for that matter). This correction is being posted to the list because his original post said nothing about removable media. mt Matt Thomlinson Say no to the Wiretap Chip! University of Washington, Seattle, Washington. Internet: phantom(a)u.washington.edu phone: (206) 548-9804 PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu

2 1

Re: quetion about Multi-user systems
by Pierre Uszynski 17 Dec '03

17 Dec '03

> On Wed, 23 Feb 1994, Eric Johnson wrote: > > [...] So perhaps I could just download my > inbox, but then sending the mail messages may be > difficult, since their is no place I can just send them. > [...] > I figure yo could just upload a file with all of your > replies and new mail, and then have a script mail each of > those letters. That way my secret key stay on my home > system, very safe, and I can use emacs to answer read and > encrypt all my mail with ease. Using kermit & Co, and then a script to transfer files composed and signed at home for mailing from your internet account is too tedious. But I believe you mentioned you are using Linux on your PC. Sooo, here are two solutions that should work in any real (non-Microsoft) window system: 1) Compose and sign each message on the PC. Then, while on-line with the remote computer, cut and paste the already-signed message directly into the remote mail line editor. (Cutting and pasting in such a way sometimes gets you in trouble with various buffering bugs, but you'll quickly figure out how much text you can paste at a time. Once a piece of text is signed, make sure you don't introduce more spaces, blank lines and such !) Once you have cut-and-paste running, it should not matter on which system you read your mail, on which one you compose new messages, or on which one you sign. Cutting and pasting very long messages will still be a pain. 2) Use a mud client (or similar) instead of kermit to connect to the remote system. Sending mail is then done by using the usual commands to get the remote system into the mailer line editor and then using a client macro of some sort to sign, transfer and send a message prepared locally. This solution will require some programming (very little on Linux, maybe quite a bit on a MacIntosh). Pierre Uszynski pierre(a)shell.portal.com

1 0

Re: quetion about Multi-user systems
by Pierre Uszynski 17 Dec '03

17 Dec '03

> Only minutes ago, I wrote: > > 2) Use a mud client (or similar) instead of kermit to connect > to the remote system. Sending mail is then done by using the > usual commands to get the remote system into the mailer line > editor and then using a client macro of some sort to sign, > transfer and send a message prepared locally. This solution > will require some programming (very little on Linux, maybe quite > a bit on a MacIntosh). Heck, you can even program all that in kermit script programs. (I have version 5A(170) here.) It's just that these programs look (incredibly) ugly. Pierre Uszynski pierre(a)shell.portal.com

1 0

re: CERT funding
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

>From Mark Hittinger: > Don't get too worried about CERT and its budget. It is precisely when someone says "don't get worried about _____" when I begin to wonder exactly what they have to hide. > The staff seemed to be all comp-sci grad student types. The main guy was > your typical visionary professor type. Before I spoke with him he was > interrupted by a call from someone at DARPA about their funding. I am > certain that he was having trouble convincing his funders that the problems > were growing and that CERT's budget should expand. I got the impression > that continued funding of CERT was not a done deal and that even keeping > the current level of funding was uncertain. Every government bureaucrat I have met says exactly the same thing. The idea is to always give the impression of being "hungry" -- if you think your budget is adequate, obvious it is too much, and if you think your sources of funding are "secure", then you are taking them for granted. Believe me ... I played the game for many years. > My point - the funding was not substantial and it was not "reliable" > funding. Their hardware was fairly recent but I did see a lot of > "old soldier" type computer equipment still in service. There was > mostly SUN, some DEC R4000 stuff, and maybe a microvaxII. Most definetly > not NSA funded. It is funded by DARPA/USAF just like most old arpanet > activity was. You are very naive! Just because something is funded by an intelligence agency does NOT mean that it is going to be a brand-new, state of the art system. The 3-letter agencies have LOTS of old but serviceable Suns, DECs, Macs, PCs, etc. internally and their contractors have the same. Yes, if they were doing cryptanalysis they'd have beefier gear, but that is not what CERT does. The problem is that when one is funded by DARPA or directly by one of the armed services, the amount of your award is supposed to be public. Usually companies announce it via a press release -- it is prestigious. HOWEVER, it is usually a condition of doing business with the intelligence community that the existence and amount of your contract award is kept secret. THat's just the way they work. Don't be lulled by the "grad-student" types either. the intelligence agencies have funded a lot of university-affiliated research. Most of the grad students and first-real-job people aren't privy to the internal funding and resposbility and deliverables of the group. Were you asked about your ability to get a security clearance? According to one article, CERT people now are getting clearances. Interesting. > I was also surprised to find out that there were several organizations > other than CERT executing the same functions for each government agency. > I learned that there was one for the navy, the dod, the cia, and probably > even the coast guard! :-) I wondered aloud about how much information > these groups shared and I got the impression that the other groups might > not have trusted CERT too much with good information. In other words > there is probably a group that you guys should be worried about because > they are deeper in the black and they don't trust the CERT guys either! > :-) :-) Yes, other CERT-type teams exist. They are collected in an organization called FIRST, the Federation of Incident Response Teams. They do share (some) info. Blackworld teams have different issues and do not generally participate, since their risk exposure is different and their issues are usually different as well. But they exist too. Sign me... "one who knows"

1 0

Stealth PGP and Stegonagraphy (LONG)
by Sergey Goldgaber 17 Dec '03

17 Dec '03

Making Stealth PGP (random noise) Files "Undetectable" INITIAL PROBLEM: The following ideas were developed in response to the concern over the future legal implications of possessing encrypted files. If non-Clipper encryption becomes illegal, even the mere possession of possible non-Clipper-encrypted files may be grounds for a search warrant, confiscation of equipment, and miscellaneous court sanctions. PRACTICAL OBJECTIVE: The possession of encrypted files must be made virtually undetectable, even to the most determined and best informed opponent. BASIC PREMISE: On many machines the file system allows users to "delete" files without actually erasing them. This is usually accomplished by simply marking the disk blocks that make up the file as free. Thus it is possible to write an encrypted (noise) file on to disk, pad the rest of the disk with more noise and "delete" the whole thing, making the disk look blank to all casual observers. CHALLENGES: I - Miscellaneous disk writes, such as those performed routinely by DOS, can overwrite the "deleted" files. II - Certain security measures on the part of the user may make recovery of the hidden file non-trivial. Ideally, the file will not have an "End Of File" marker, a file name, nor an entry in the File Allocation Table. III - Upon examination of the deleted segment of a disk, the aware opponent will notice the discrepancy between a large, highly-random noise-segment and the "structured garbage" that will make up most of the rest of the deleted portion of the disk. PROPOSED SOLUTIONS: I - To ensure the integrity of the hidden data, all disk writes must be directly controlled by the user, not DOS. A - Use of a floppy disk is recommended; as, controlling each individual disk-write operation on a harddrive becomes infeasible due to the large amount of said operations. B - The user should specify and keep track of the exact address and length of the encrypted file when writing it to disk. The file's location/length should be guarded as dearly as one's secret key and corresponding password, for similar reasons. II - Keeping track of the exact address and length of the hidden file will allow easy file recovery, without need for an EOF marker, a file name, nor a FAT entry. III - In order to make one's file deleted file virtually indistinguishable from the rest of the deleted portion of the disk, the implementation of one of the following measures is recommended. A - Split the noise file into small individual files and scatter them throughout the "structured garbage" that is already on the disk. It should blend in with the other little pieces of highly random noise that are naturally interspersed in the deleted portion of the disk. Recovery would, of course, require one to keep track of the addresses, lengths, and order of the component files. B - Use a stegonagraphy utility to hide one's file in a segment of "structured garbage". A Mimic function with a "structured garbage" grammar would be highly usefull for this. DISCUSSION: All of the above speculation relies on the use of Stealth PGP, or a similar program that encrypts plaintext into a format indistinguishable from random noise. Unless this stegonagraphic function is implemented detection of the encrypted file, even when hidden among megabytes of other "deleted" files, will be trivial; as, PGP has a distinct header. The success of the above method also relies on the use of non-standard locations for the hidden files. For, if this method becomes popular, _and_ everyone starts hiding their files in the last few sectors of the disk, for example, a significant portion of the method's effectiveness may be compromised. It should be noted that as long as the user is writing directly to and reading directly from the disk (bypassing DOS), "deletion" of the file is no longer necessary. It is necessary to keep the blocks one writes to marked as "FREE", "BAD" or "DELETED" (take your pick!). Some modification of the FAT or equivalent may be required here. SUMMARY: In order to hide a Stealth PGP (or equivalent) encrypted "noise" file effectively one may follow the steps outlined below: 1 Embed it in "structured garbage" such as is present normally on the deleted portions of the disk. This can be accomplished by using a stegonagraphy program or by splitting the file into small segments and scattering them among "structured garbage". 2 Write the resulting "structured garbage"/noise combination directly to disk. This can be accomplished by using a normal disk-sector editor utility. 3 Keep track of the exact location and size of the file if you want to retrieve it later. Keep this information secure. 4 Modify the FAT (or equivalent) to mark the sectors you've written to as "FREE", "BAD", or "DELETED" (if necessary). In order to retrieve and reconstruct one's file simply reverse steps 2 and 1. THANKS: I wish I could thanks everyone who has commented on this thread individually. Unfortunately, I am rather new to this. Next time, I'll know to keep track of each response/address/name instead of simply replying to your mail/posts. You know who you are. Thank you! Keep you comments flowing! All feedback welcome, Sergey

1 0

Stealth PGP and Stegonagraphy (Summary)
by Sergey Goldgaber 17 Dec '03

17 Dec '03

In order to hide a Stealth PGP (or equivalent) encrypted "noise" file effectively one may follow the steps outlined below: 1 Embed it in "structured garbage" such as is present normally on the deleted portions of the disk. This can be accomplished by using a stegonagraphy program or by splitting the file into small segments and scattering them among "structured garbage". 2 Write the resulting "structured garbage"/noise combination directly to disk. This can be accomplished by using a normal disk-sector editor utility. 3 Keep track of the exact location and size of the file if you want to retrieve it later. Keep this information secure. 4 Modify the FAT (or equivalent) to mark the sectors you've written to as "FREE", "BAD", or "DELETED" (if necessary). In order to retrieve and reconstruct one's file simply reverse steps 2 and 1. For a more detailed discussion of the above method, see the associated message, entitled "Stealth PGP and Stegonagraphy (LONG)". Sergey

1 0

Re: STEALTH OCEANS (fwd)
by Sergey Goldgaber 17 Dec '03

17 Dec '03

On Thu, 24 Feb 1994, Matt Thomlinson wrote: > > Sergey Goldgaber <sergey(a)delbruck.pharm.sunysb.edu> writes: > > >> might work, except for the fact that fragmentation _does_ go on, and when > >> you were to write files to the drive (heck, I do every time I start up > >> windows and write a huge temp swapfile) you're going to be playing > >> roulette with your data. > > >This problem is solved by simply using a utility that writes directly to the > >disk (exactly in the specified sectors, in the specified order), instead > >of letting DOS fragment your disk. > > > I've been talking to Sergey behind the scenes, and I think I understand > what our miscommunication was: he is proposing this type of technique > ONLY for removable-type media, e.g. floppies. I am proposing this as a practical solution that can be implemented effectively mainly on floppies. Hard-drives might have to be dedicated to stegonagraphy (As Matt points out below). > To store this type of data on your harddrive would be to dedicate your > harddrive to stego. This was my argument all along; what we failed to > connect on was the fact that only floppies are involved. With floppies, > every write *can* be controlled and the data would be relatively safe (and > obscure, for that matter). > So it seems. However, I am wary of the possibility that there are drawbacks to the scheme that I haven't even considered yet. I'm hoping that other astute readers such as yourself may be able to point them out; as, practical stegonagraphy may become a necessity in the near future. > > This correction is being posted to the list because his original post > said nothing about removable media. > My original post only outlined the basic premises. I had not, at that point, realized that floppy use would be a virtual necessity. > > mt > > Matt Thomlinson Say no to the Wiretap Chip! > University of Washington, Seattle, Washington. > Internet: phantom(a)u.washington.edu phone: (206) 548-9804 > PGP 2.2 key available via email or finger phantom(a)hardy.u.washington.edu > > Thanks for your insights and neverfailing tenacity, Matt. Sergey

1 0

Re: CERT funding
by smb＠research.att.com 17 Dec '03

17 Dec '03

Thanks, Mark, for an interesting posting about CERT. Let me add just one or two comments about the place. That CERT should be interested in software engineering is a very good sign. What do you think causes most security holes? It *isn't* lack of cryptography, for the most part, though this last big incident is an obvious exception. The answer, of course, is bugs in the code -- and to that, software engineering is the only answer from computer science as a whole. (Bob Morris Sr's keynote address at the last UNIX Security Conference was entitled ``if your software is full of bugs, what does that say about its security?'') As for the database stuff -- from what the folks at CERT have told me (and yes, I know some of them quite well), they're having a problem managing the tremendous volume of bug reports, incident reports, etc. They need to do their own tool-building. Finally, there are some folks at CERT who are *extremely* sharp. I don't know who you talked to, but there are people there I'd hire in an instant if they were available.

1 0