Don wrote: Run VMS ;-)

Don wrote: hacker proof. Just google for "vms defcon 9"

On Aug 18, 2006, at 3:55 PM, Alexey Toptygin wrote: Ahhh, somebody doesn't know how widely deployed VMS systems are, but I won't point any fingers! -Dave -- Dave McGuire Cape Coral, FL

On Aug 21, 2006, at 7:01 PM, Alexey Toptygin wrote: Sigh. I didn't say anything other than what I typed above. The world is full of misguided and/or clueless people who think VMS is "old", "dead", "legacy" or some other such nonsense, while in fact it is extremely widely used...just not in places that we hear about every day. VMS is not cracker-kiddie-resistant because it's obscure...it's cracker-kiddie-resistant because it's well-written. -Dave -- Dave McGuire Cape Coral, FL

VAX machines are often found in the financial world, as well as in military, manufacturing and process control. See below. No doubt that there are far fewer VAXes (I hate using VAXen), but they are much better targets. I bet 99 percent of the Unix machines on the Internet basically are really boring machines, a good number of which have their fair share of porn. A much larger percentage of VAX machines hold much more interesting bits and things to screw up - and in the case of banking, VALUABLE bits. I hear pretty much the same thing from all of the hackers I know - VMS (and OS/400*) is just about buttlet proof. *And before you ask, AS/400s are very common in the business world. There are a huge number of the machines out there. -- Will

On Aug 22, 2006, at 2:49 PM, Alexey Toptygin wrote: They're Alphas, actually. Talk to Eric Dittman <dittman at dittman.net>. He manages dozens of them, and works in an industry populated almost entirely of them. He used to be on this list, but he unsubscribed because of misinformed (but vehement) people such as yourself. In fact, I'm beginning to think you're actually Dick Erlacher operating under a different name. The majority of production VMS machines today are Alphas, not VAXen. Do your homework before YOU start making grandiose claims. -Dave -- Dave McGuire Cape Coral, FL

On Fri, 18 Aug 2006, Don wrote: This is commonly done, and called W^X (write xor execute). See: http://en.wikipedia.org/wiki/W%5EX Many can be, which is why OpenBSD among others implements it. This is how they were able to make the "no remote root vulnerabilities in X years" claim. However, securlty experts have been able to exploit many stack bugs despite this protection, usually with "return to libc" attacks. There are many papers out there on how to exploit a W^X protected process, and many others on additional protections that defeat these attacks. Mostly these protections rely on randomizing the address space of a running process or changing the calling convention so stack integrity is verified somehow before each return. There is a ton of work in this area, W^X is just the simplest and most efficient (and maybe oldest) method. Some people have gone so far as to statistically profile the pattern of system calls an application makes, and to kill it if the pattern suddenly changes (this is the least practical approach I've heard of :-). Alexey

On 8/18/2006 at 3:17 PM Don wrote: Why are protections primarily reserved for OS-level tasks? Why not subset protections within the user area? A user should be able to say that a plugin or DLL should have only a certain limited number of privledges. Cheers, Chuck

Alexey Toptygin wrote: Or, in a microkernel/multiserver environment, between any two *services*/client/etc.

On Fri, 18 Aug 2006, Brad Parker wrote: Why? Why should I tell myself that there are no pointers if in fact pointers are in use? If I close my eyes will the processor stop addressing memory? I don't thinks so. No, it bloody well doesn't. Security has never magically appeared. You can't give up pointers for lent and discover you've become hackerproof. Abstraction does not stop someone from using the raw capabilities of the machine. Only by taking away the ability to write to protected memory can you achieve security. Seriously. Alexey

Josh Dersch wrote: This can only be possible if applications are *interpreted* AND the user is denied *any* means of accessing the underlying hardware (either by accidental or *intentional* means). It's like claiming "run Java/Inferno/etc. on your machine and you'll never have to worry about security issues" (unless, of course, someone boots the machine to a "non-Java" state!)

Josh Dersch wrote: Of course. But the intent was to avoid the "performance penalties" of using hardware mechanisms. So, (in existing hardware) you trade the use of those facilities for the overhead of an interpreter (regardless of what you want to call it) Because most machines nowadays are in the hands of people who aren't savvy enough to understand these issues. I.e. you can't have physical security since there is nothing preventing a user (*owner*) from circumventing this key step knowingly or unknowingly. E.g., any sort of removable media that can be passed control of the processor outside (i.e., before) the scope of your VM leaves the system vulnerable. Hence the reason many PC's are configured without (or with *disabled*) floppy and/or CD-ROM drives in business environments. Getting a robust system into a consumer's hands is considerably harder than one sitting in a machine room :>

Josh Dersch wrote: Sorry, I was responding to the Singularity *literature* (though *through* you :>) Yes, but the latter is effectively the case for PC users nowadays. Even if they chose not to run as "Administrator" 24/7, they still are TOLD to run as Administrator when installing software. Yes, but not all "infections" are intentional. I.e. installing buggy code is still buggy code. Even if the manufacturer didn't intend it to be so. Of course! As I said in a previous post, this is something near and dear to me as I have to build products that are potentially compromised by these avenues. Each time you raise the bar, "clever" (??) users find some other stupid thing to do that compromises the measures you've taken to maintain system integrity. I pity those folks who design "PC-based" products! (it's just too easy for users to think "Oh, this is a PC! I can ________ "

Ray Arachelian wrote: You're actually suggesting writing multithreaded, JDBC connection code in raw assembly because it's more obvious when you've screwed up? Not sure I follow the reasoning (I'd suggest hiring more experienced Java coders), but more power to you on that effort :). I hear this argument all the time (used to be about Visual BASIC) and while I agree that making coding easier lowers the barrier to entry to our "elite" club of the high UNIX priesthood, I don't think that it's a valid argument to blame the language rather than the people involved. Josh

Well, I seem to have struck a nerve here, now haven't I? I was intending my comment to be mostly tongue-in-cheek, but I guess I failed on that count. Next time I'll use more smileys. So your argument seems to be that the experience to know that JDBC and file handles are the exception to the rule is necessary here. No argument there. It's an unfortunate issue with the language (or it may be an unfortunate issue with the way the JDBC libraries are written). The same mistakes can be made in any other language that lacks a GC. How does one write memory allocation code in Java? As far as I know, there's really only one interface to it and it's provided by the runtime. If you're talking about being wasteful with memory, that's one thing... but you can be wasteful with memory in any language with no skill involved. I posit that you can write crappy code in any language and still get away with it. Hell, I'd say it's a lot easier to write crappy code in C. The things I've seen done with pointers... ugh. As for C _enforcing_ writing better code (solely due to lack of a GC?) -- you're kidding right? It enforces _knowledgeable_ programmers to be 100 times more careful (and the key here is _knowledgeable_) , but it won't prevent _anyone_ from shooting themselves in the foot without even knowing it even if they think they are being careful (buffer overruns, invalid pointers, etc). That's why this thead about stack-smashing got started in the first place, eons ago... I don't know about Java specifically, but I know that for C# there are profiling tools to help you nail down memory leaks when they occur. I assume that these also exist for Java. If you're looking for memory leaks solely based on memory footprint of the process, then yes, you're going to have problems. I agree with the sentiment, but I still disagree that "inexperienced programmers" is a shortcoming of the language. I can see every programming language on earth falling into this bucket. I have done no such thing. I merely sought to point out a flaw in a proposition you made -- that it would be better to replace easily maintainable/portable (in the _right hands_) code written in a high-level language, dealing with high-level concepts (database access, multithreading) with hand-built assembly code. And you propose doing this _only_ because it somehow magically causes people to make fewer mistakes with memory allocation. I don't think this is a reasonable argument. There is a place for assembly code, but I don't believe this particular case is one of them. I'd also argue that one can make many more mistakes much more easily in assembly, even if one manages to allocate memory correctly. I think the argument you're really making here is that _experienced_ programmers (ones who have dealt with low-level languages like assembly and C) know the pitfalls of memory allocation, file handles, performance issues, etc... and as such could make much better use of Java. What you're really saying is that you need to hire better programmers, and that some programmers need to be better educated in computer architecture. I don't necessarily disagree. All languages have issues. What I disagree with is your earlier claim that rewriting code better suited for high-level languages in assembly is some sort of magic bullet that would somehow reduce programmer error. If you gave the same Java coder who's borking up the JDBC connections the task to rewrite it in assembly I doubt very much that person would come up with an error-free implementation in a reasonable timeframe. I think it would be far more productive to sit down with the coder, beat him with a LART and explain that JDBC and File handles need to be closed (and why!). Josh

Ray Arachelian wrote: It's the OS's responsibility to play policeman -- not the language. That's been The Way of The World ever since machines were invented. And, I suspect it will continue to be so. An implicit goal of software engineering is to make it easier for folks to express their ideas -- and let the machine handle all the grunt work. The fact that less and less skilled people are writing code (in a particular language) is a natural consequence of that. Personally, I want languages to let me do what I want to do, and *how* I want to do it. Without artificial constraints E.g., if I want "I" to represent *amps* -- as a real -- and "A" to represent *artichokes* -- an *integer* -- I dont want a language implicitly forcing some other types on me based solely on the naes I have chosen, etc. (silly example of something that a machine can -- and should -- do for me). It *is* amusing to see how all of these "improvements" apparently haven't resulted in better code... :-(

Dave McGuire wrote: D'uh... :> Yes, but *enforcement* is the role of the OS -- as "manager of system resources".

Rumor has it that Don may have mentioned these words: I'm not sure why you'd need to track how many amps you're passing thru artichokes, but remind me never to eat supper at your house!!! ;^> Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | "Bugs of a feather flock together." sysadmin, Iceberg Computers | Russell Nelson zmerch at 30below.com |

Am I the only person here who is reminded of using a slice of potato to determine the polarity of a DC supply? -tony

I actually have a book of electrical things for boys to make which suggests makine a sausage cooker that simply connects said sausages across the (110V) mains. Hmmm.... I am trying to rememebr other ways of determining the polarity of a DC supply. There was, of course, stuff called 'pole finding paper' but nobody seems to sell it anymore. And the well-known earthworm on damp blotting paper, but I can't rememebr whethter the head is +ve or -ve for it to stretch... -tony

Personally, I'd rather use a step-down _isolating_ trasnformer :-) That is one type of 'pole finding paper (this is chemically-treated strips of paper that you moisten, then put the wires on the ends of said strip. It changes colour at one end, giving the polarity of the supply). Another well-known one is a mixture of starch and potassium iodide. At one time (before my time) you could buy pole-finding paper from electrical shops (or so I am told). These days only eccentrics like me have even heard of it Yes, a friend at HPCC claims to be able to do that. We've never needed to put it to the test, though (I have a Fluke DMM at the meetings...) -tony

When I was in university (70s), I had a hot-dog cooker which cooked weiners by connecting them across the 110v AC mains. This was a commercially produced device. The device looked like a 1/2 cylinder with a same-shape drawer that you could remove from one end. When removed the drawer had points along the sides where the round part of the cylinder meets the flat part of the cross section, angled such that you could put up to 6 weiners with an end at matching points, and each would curve up in an arc inside the half cylinder (you had to push the weiner into the points so that they penetrated into the end). When you inserted the drawer full of meat into the outer shell contacts on one end would connect each row of poins with one side of the AC mains (the idea was that the points were not powered until the drawer was fully inserted, thus preventing body contact with electrically hot points. It actually worked, but much better for some brands of weiners. (Some were not very conductive at all) - you would get very odd looks from store owners when you asked which weiners were most conductive. Regards, Dave -- dave06a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.classiccmp.org/dunfield/index.html

On Tue, 22 Aug 2006 17:44:01 +0000, Jules Richardson wrote: Not a comercial product, yet a great educational example: http://tinyurl.com/lf7cs This 1950's version is more ontopic :) http://tinyurl.com/mn8eg There have been numerious ways for a cool cat to heat a dog .... ok ... Back under my rock, I go :)

----- Original Message ----- From: "Tom Peters" <tpeters at mixcom.com> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Tuesday, August 22, 2006 3:10 PM Subject: Re: OT: Hotdog cooker links was I recall a TV show a long time ago (some guy showing kids how things worked) was showing how to cook a hotdog like that (I think they used those small forks that you held corn on the cob with) and plugged them into 110VAC for a few seconds. The salty liquid in the hotdog conducted enough electricity to cook the hotdog in a few seconds. I bet that show never gets replayed these days because of lawyers.

Bryan Pope wrote: Hmm, raw beef has a dielectric constant of 49 at 20C :-) Chad Fernandez Michigan, USA

On 8/22/06, Don North <ak6dn at mindspring.com> wrote: I've never blown one up, but I have cinged them well beyond the point of being even close to edible. The effect is called Sodium-D Line Emission. There have been a few papers written on the subject, including one by seven engineers from DEC, titled "Characterization of Organic Illumination Systems". This paper should be available on the Compaq website, but it can't seem to find it right now. (Interestingly, they also studied stir-fried bok choy and raw mandarin oranges.) Penn & Teller printed directions for the pickle light in their book "How To Play With Your Food" (great book, btw), and it really does work. Pretty neat, gives off an odd yellowish glow. You can find info on how it all works, and how to make your own at: http://tinyurl.com/jku95 Best wishes, and always use a gfci or a really big stick. Shaun -- "If you live to be a hundred, I want to live to be a hundred minus one day, so I never have to live without you." -- Winnie The Pooh http://www.lungs4amber.org

David Griffith wrote: A bit of trivia, the reason you see a lot of HP/Compaq mentioned in these is because the guys that built the Alpha chips worked at DEC, which as bought by Compaq. The Alpha chips were coded with EV - as in Electro Vlassic. :-) http://www.linuxsa.org.au/pipermail/linuxsa/2000-November/022525.html

Tony Duell wrote: Tony, I found that with Google. I found similar numbers at different temps. Cooked was much lower.... around 4. Chad

On Tuesday 22 August 2006 01:26 pm, Chuck Guzis wrote: Yeah, we have one of those someplace. Dunno where the heck we're gonna get another set of electrodes for it, though, the ones in there are all corroded to heck... :-) -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Dave Dunfield wrote: So what brands work best?

Jules Richardson wrote: Why not just buy the book! I think they have have re-print at www.lindsaybks.com

Ethan Dicks wrote: I was thinking of a different title ... mind you this book has the sausage cooker in it. http://www.lindsaybks.com/bks9/ething/index.html now just what is a electric popcorn cooker ???

I think the book is still available (as a reprint). The title is somethign like 'Electrical Things that Boys Like to Make', it is (was?) available from Camden's (IIRC it's a Lindsay Books reprint). Many of the projects would give the Health and Safety Nazis fits these days. Asbestos board, anyone? -tony

On 8/22/2006 at 7:18 PM Roy J. Tellason wrote: The really old turn-of-the-century books have the kids using sulfuric acid, mercury, lead and lead salts,... Sometimes I think we're a bit overprotective. Cheers, Chuck

On 8/22/2006 at 11:33 PM Roy J. Tellason wrote: "Make your own secondary cells" (H2SO4 and Pb) "Low resistance contact switches" (Pool of mercury into which a a contact is lowered "Make your own voltage calibration source" (Weston or Clark cell) Sometimes the old texts have very clever ideas. I have an old book on building pipe organs with electrical key action. Power on/off was achieved not through a switch, but by lowering and raising the electrodes of a bank of wet Leclanche cells in and out of the electrolyte using a pneumatic bellows. The same text recommends winding electromagnets with insulated iron wire rather than copper, to keep current draw down by virtue of iron's higher resistance. Cheers, Chuck

Sulphuric acid is not _that_ dangerous, particularly if dilute. Mind you, I once had a long argument with a medical doctor who tried to convice me that hydrochloric acid is toxic. I wonder what he thought was in my stomach? At least one of my old electrical books -- I think it's 'Harpers Electricity Book for Boys' dating from 1907 [1] -- has you doing gold plating using gold and potassium cyanides (!). [1] Yes, it's an original, not the Lindsay reprint. And it's not the oldest electrical book I own. I have a few books on electric bells and telephones dating from before 1900. Yes, I like old books... Well, the darn govenrment is, that's for sure. -tony

I still wouldn't want to drink it... Nitric acid is difficult to obtain over here because of the obvious (?) use in nitrating things. -tony

I would not want to drink HCN (prussic acid) at any concnetration. No, I disagree. If I took, say M/10 HCl and drank a glassful, it wouldn't do me any lasting harm. It would be no worce that vomiting. Not pleasant, but I'd live to tell you about it. No, to wirthstand the corrosiveneess. When I vomit, thr stomach acid comes up the tube it would go down if I drank some acid. As I said, it's not pleasant, but it's not fatal either. -tony

On Monday 21 August 2006 06:04 pm, Tony Duell wrote: No, though it's been so long since I've even thought of that one I can't remember which end is which any more. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

Actually, it does, or at least can. You do have to get your head out of the "what the library provides is raw machine code" mindset before you can understand how, though. Again, it can. All you need to do is make sure that the code the library provides is handed to the p-code engine (or moral equivalent) rather than directly to the processor. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Don wrote: That's all fine and good, but in the end, it only addresses a very small class of security flaws. Running untrusted code in a VM (or chroot jails, etc) are a good way to isolate it, but the core issue is that said code is untrusted. You can prevent a few types of exploits in the extent of the damage they can cause, but that's about it. If you code you're running has security flaws, or back doors, you'll still be affected by them, just to a lesser degree, since anything that allows an opponent to gain remote control of that code would be locked down to that sandbox. A VM is not a total security fix. Remember that the VM or emulator is a Turing Universal Machine. The definition of which is a machine that can do everything some other machine can. This includes the execution of the very same security holes you're trying to prevent. No matter how many layers of abstraction you wrap around something, a security flaw is still a security flaw, and there are no easy fixes. You can fix and prevent buffer overflows, you can fix and prevent stack smashes without VM's. VM's however are good at isolation of data, and rolling back state. You can use them to run a web browser and prevent access to your financial files from that web browser. If something takes over your web browser, you can undo all the changes by shutting it down, reverting the data untrusted code, you haven't fixed any security hole, but what you've done is to have turned a remote access exploit into a denial of service exploit. A good trade, IMHO. What you gain with a VM is a bit more than what separate computers (known as an air gap) gain you. Unless there are flaws in the VM that allow a remote access exploit to escape the VM. Going back to the web browser example, if you use a VM to surf the web, and happen to download an interesting program, or update that you trust, but is actually malware, and run it outside the VM, you haven't won anything by using the VM. This is a policy issue, because at that point, you've violated the constraints of the air-gap. VM's are not magic bullets, although they're very useful. In the end, there's only the question of what's your threat model, and what's an acceptable risk.

On 8/19/2006 at 12:49 AM Alexey Toptygin wrote: I don't think so. There is a subset of all DLLs that can be classified as "trusted"--they know to check arguments and the operation is well-defined. One might classify these as "friendly" DLLs and omit any sort of checking. For all others, the calling program can specify a tighter degree of control at the expense of more overhead. Cheers, Chuck

This talk about stack smashing brought up an interesting memory. I don't think I've ever seen a description of a special project that I worked on in the early 70's while at CDC SSD. This was a project for the Air Force Logistics Command, called Advanced Logistics System or ALS. The idea, which was pretty darned advanced for the time, was to maintain a real-time online database of all materials worldwide managed by AFLC. Each item would be tagged with a card and its status and location maintained in a large shared database as it moved through the system. Notions of equivalent and substitutible items were part of the process and a whole pile of software that dealt with making tradeoffs on time-to-delivery and priority was to be written. Yes, this also included nuclear devices. The programming of the applications was done by something like 1400 GSA personnel writing reams and reams of COBOL. Initially, most of the big-iron vendors submitted responses to the RFP. The first time, only CDC managed to pass the benchmark and it was decided to release a revised RFP that would enable more than one vendor to qualify. In the end, IBM managed to get the benchmark to run, but refused to submit a bid. This project was a huge cash cow for CDC, bringing in over $500M over the first half of the 1970's. The hardware was pretty straghtforward. Up to 4 CYBER 74s couipled to 4MW of ECS and multiple-access controllers on the mass storage (a farm of 844 disk drives), tapes and unit record equipment. Remote terminal equipment was 1700 minis connected to various third-party small card-handling equipment. I think the modems for the leased lines were Milgo. But the operating system was the interesting part. An application consisted of a number COBOL modules, each running as an independent task grouped together in a job called a "chain". Modules were normally resident in ECS and swapped into any available machine for running. Inter-module communication was performed via a special COBOL CALL statement, with normal COBOL parameter passing. Each machine cluster could run 128 chains consisting of 64 modules. The odd part of this was that all of those wonderful COBOL rules for parameter conversion had to be implemented in executive (privldeged) mode. In fact, other than for device drivers, the whole operating system was located in the CPU, which was very unlike most other CDC operating systems. Data management was a bit bizarre, operating outside of the normal file system, but running as its own set of modules. Eventually, Proxmire called a halt to the project, but I think it represents an interesting milestone in large online database applications. I don't recall any protection issues arising as part of this. Each module was constrained by its own RA and FL and communication with other modules was vetted by the OS executive. To be fair, the CDC machines did not have to deal with issues of virtual memory and the XJ instruction was very fast, saving and reloading the entire register file more than twice as quickly as it could be done with programmed loads and stores. While never implemented, it would have been easy for the lead (master) module in each chain to constrain what a member module could or could not do. Database record locking was done on a module basis, but a lock could be passed from one module to another within the same chain. Yet, I don't think one CDC programmer in 50 back then had ever heard of the OS, called TCM (eventually rechristened Zodiac in honor of a certain personage that was haunting the Bay Area at the time). I doubt that even the most hard-bitten CDC retro freak even remembers it now. Another blast from the past. Cheers, Chuck

AS/400. Properly. -- Will

Google around for info on AS/400 architecture basics (although the nitty gritty details will not be found, as IBM keeps those to themselves). -- Will

On 8/18/2006 at 5:59 PM Jules Richardson wrote: Windows Sloppy programming (really, there's no excuse for not including bounds-checking when decoding)is a big part of the picture. In Windows' case, a lot of the vulnerabilities seem to be a combination of sloppy coding and including "features" that have vulnerabilities inherent. (e.g. OLE in browser applets, executables in email attachments...) Of course, if a set of object libraries with inherent vulnerabilities in them is used, bugs get re-used too. Cheers, Chuck (Looking at something like 13 "security" patches to Win2K this month)

On 8/18/2006 at 11:39 AM Don wrote: Absolutely. I suppose that some of Windows' bugginess comes from having to use third-party drivers and services for things not "standard legacy". Something that Apple really doesn't have to worry about too much. But allowing malicious code to creep in through one's own email and browser is not a sign of good design. Certificates have pretty much proven to be worthless in that respect. "Undocumented" features don't help either. --Chuck

Chuck Guzis wrote: Same with LINUX ... Dynamic Link Libraries are the *root* of the problem with the NEW OS's.

David Holland wrote: Yes, but if your OS marked data segments as "no execute", this problem would go away, right? You would then be forcing the hacker to twiddle the stack in the hopes of getting some *unintended* portion of *your* code to execute -- but that code would have to reside in a loaded TEXT segment (else it would be "no-execute") Or, is there some *other* way around this that I haven't anticipated? :-(