Memory purge
Dave Dickerson
that content of RAM has been erased/overwritten?
I have a SCO OpenServer 5.0.5 Desktop machine that processes sensitive data
that will soon be under security requirements that should RAM need replacing,
the old RAM must be erased/overwritten (by some number of passes of 0's & 1's,
I assume) before removal.
Not sure how to satisfy the requirement. Of course, another requirement is that
it cannot cost anything to satisfy the first requirement.
Any suggestions?
-------------------------------
DD in AZ
------------------------------
To get a working email address
replace nospam with dickers
------------------------------
Tom Parsons
| What would one do, by way of running a command or command script, to assure
| that content of RAM has been erased/overwritten?
|
| I have a SCO OpenServer 5.0.5 Desktop machine that processes sensitive data
| that will soon be under security requirements that should RAM need replacing,
| the old RAM must be erased/overwritten (by some number of passes of 0's & 1's,
| I assume) before removal.
|
| Not sure how to satisfy the requirement. Of course, another requirement is that
| it cannot cost anything to satisfy the first requirement.
Depending on local availability, these may or may not be no cost items.
16 lb sledge hammer (an 8 would do but why be a wimp) <g>
Grinder
Arc Welder
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Jeff Liebermann
>What would one do, by way of running a command or command script, to assure
>that content of RAM has been erased/overwritten?
Ummmm... reboot.
>I have a SCO OpenServer 5.0.5 Desktop machine that processes sensitive data
>that will soon be under security requirements that should RAM need replacing,
>the old RAM must be erased/overwritten (by some number of passes of 0's & 1's,
>I assume) before removal.
Dynamic RAM does not permanently store bits. Turn off the power, and all
the stored bits are cleared.
>Not sure how to satisfy the requirement. Of course, another requirement is that
>it cannot cost anything to satisfy the first requirement.
Well, that eliminates immolation, explosives, microwaves and magnetic EMP
fields. A good reference book on the topic of destroying data (and
computers) can be found in:
"Information Warefare" by Winn Schwartau Pp768, ISBN 1-56025-132-8 $17.
However, since you insist on economy, I suggest you simply run:
sync; sync; sync
/usr/bin/yes "Garbage and more garbage" > /dev/kmem
which is guaranteed to overscribble all of memory. This only works once.
It might also destroy all the data on your hard disk, but will certainly
vaporize anything left in memory. You will need to reboot afterwards. I
would give the OS a 50% chance of surviving this exercise.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Jeff Liebermann
>Reboot. I agree. But the regs want some kind of proactive process done that
>"touches" each memory address. Sort of like Norton's wipe for magnetic media.
>
>Your last suggestion, with the redirection to /dev/kmem, will that write to all
>memory address?
Oh swell. You're serious. I hate that.
If you scribble all over /dev/kmem it will screw up all of RAM including
the operating system. Your machine will promptly go insane, belch bytes,
and probably initiate a nuclear attack. It's the OS equivalent of throwing
a wrench into the machinery. Don't do it.
What you should be worrying about is the contents of the hard disk, not the
RAM. Unlike RAM, the hard disk contents are not volatile. 30 seconds
after booting your machine, the evil empire will have the entire contents
cloned onto backup media and into the hands of the dark side. The
rebellion will flounder and emperors storm troopers will defeat the rebels
of the conglomeration. Obviously, this is highly undesireable.
Removing the hard disk before offering your computer to the high priests on
the altar of repair is a bit like getting your car repaired without the
engine. The chances of success are rather limited. However, if you're
really paranoid, just find some other hard disk, load it up with your
favorite OS, and may the force be with you.
Richard Howlett
>
> What would one do, by way of running a command or command script, to assure
> that content of RAM has been erased/overwritten?
>
> that will soon be under security requirements that should RAM need replacing,
> the old RAM must be erased/overwritten (by some number of passes of 0's & 1's,
> I assume) before removal.
Troll alert! Troll alert!
--
Richard Howlett
mailto:ric...@howie.org.uk
Dave Dickerson
>
>Dave Dickerson enscribed:
>| What would one do, by way of running a command or command script, to assure
>| that content of RAM has been erased/overwritten?
>|
>| I have a SCO OpenServer 5.0.5 Desktop machine that processes sensitive data
>| that will soon be under security requirements that should RAM need
replacing,
>| the old RAM must be erased/overwritten (by some number of passes of 0's &
1's,
>| I assume) before removal.
>|
that
>| it cannot cost anything to satisfy the first requirement.
>
> 16 lb sledge hammer (an 8 would do but why be a wimp) <g>
> Grinder
> Arc Welder
>--
>==========================================================================
> Tom Parsons t...@tegan.com
>==========================================================================
Too heavy-handed for the situation. Let's assume the machine is going out for
repairs to an uncleared facility. Will need the RAM when the machine is
returned.
Dave Dickerson
says...
>
>On 2 Jan 2000 22:04:28 GMT, nos...@primenet.com (Dave Dickerson) wrote:
>
>>What would one do, by way of running a command or command script, to assure
>>that content of RAM has been erased/overwritten?
>
>
>>I have a SCO OpenServer 5.0.5 Desktop machine that processes sensitive data
>>that will soon be under security requirements that should RAM need replacing,
>>the old RAM must be erased/overwritten (by some number of passes of 0's &
1's,
>>I assume) before removal.
>
>the stored bits are cleared.
>
that
>>it cannot cost anything to satisfy the first requirement.
>
>fields. A good reference book on the topic of destroying data (and
>computers) can be found in:
> "Information Warefare" by Winn Schwartau Pp768, ISBN 1-56025-132-8 $17.
>
>However, since you insist on economy, I suggest you simply run:
> sync; sync; sync
> /usr/bin/yes "Garbage and more garbage" > /dev/kmem
>which is guaranteed to overscribble all of memory. This only works once.
>It might also destroy all the data on your hard disk, but will certainly
>vaporize anything left in memory. You will need to reboot afterwards. I
>would give the OS a 50% chance of surviving this exercise.
>
>
>
>Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
>(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
>http://www.cruzio.com/~jeffl WB6SSY
>je...@comix.santa-cruz.ca.us je...@cruzio.com
Reboot. I agree. But the regs want some kind of proactive process done that
"touches" each memory address. Sort of like Norton's wipe for magnetic media.
Your last suggestion, with the redirection to /dev/kmem, will that write to all
memory address?
Tom Parsons
| >| that content of RAM has been erased/overwritten?
| >|
| >| that will soon be under security requirements that should RAM need
| replacing,
| >| the old RAM must be erased/overwritten (by some number of passes of 0's &
| 1's,
| >| I assume) before removal.
| >|
| that
| >| it cannot cost anything to satisfy the first requirement.
| >
| > 16 lb sledge hammer (an 8 would do but why be a wimp) <g>
| > Grinder
| > Arc Welder
|
| repairs to an uncleared facility. Will need the RAM when the machine is
| returned.
Well, you did ask for a cheap and definite solution <g>.
The memory isn't the issue, a fraction of a second after power off, the
memory is erased. Are you going to remove the hard drives when you
send the machines out for repair? That is where the data lives.
John Temples
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>Dynamic RAM does not permanently store bits. Turn off the power, and all
>the stored bits are cleared.
DRAM can maintain its contents for seconds, even minutes, after
losing power. If absolute certainty is required, removing the power
isn't good enough.
>However, since you insist on economy, I suggest you simply run:
> sync; sync; sync
> /usr/bin/yes "Garbage and more garbage" > /dev/kmem
>which is guaranteed to overscribble all of memory.
Including the kernel and the "yes" executable and its shared
libraries which are all resident in memory. You'd have no guarantee
that all of memory was wiped before the wiping program itself was
wiped.
I see no way that this can be accomplished under something like OSR5.
I think you'd need a dedicated program you could boot from a floppy
to do the job. Or swap the RAM modules before handing the machine
over to the insecure party.
--
John W. Temples, III
Radek Tomis
> Organization: Committee To Maintain an Independent Xenix
> Sent: Monday, January 03, 2000 7:33 AM
> On 3 Jan 2000 04:24:26 GMT, nos...@primenet.com (Dave Dickerson) wrote:
>
> >Reboot. I agree. But the regs want some kind of proactive process done
> >that "touches" each memory address. Sort of like Norton's wipe for
> >magnetic media. Your last suggestion, with the redirection to /dev/kmem,
> >will that write to all memory address?
>
> Oh swell. You're serious. I hate that.
>
> If you scribble all over /dev/kmem it will screw up all of RAM including
> the operating system.
"/dev/kmem" != "/dev/mem"
> [...]
--
Radek Tomis
r...@mediumsoft.cz
Jim Richardson
je...@comix.santa-cruz.ca.us wrote:
> On 3 Jan 2000 04:24:26 GMT, nos...@primenet.com (Dave Dickerson)
wrote:
>
> >Reboot. I agree. But the regs want some kind of proactive process
done that
> >"touches" each memory address. Sort of like Norton's wipe for
magnetic media.
> >
> >Your last suggestion, with the redirection to /dev/kmem, will that
write to all
> >memory address?
>
> Oh swell. You're serious. I hate that.
Jeff:
As usual, when someone comes to you with a real problem, you mock
them. Shame shame shame.
I see two possible solutions, both are relatively inexpensive although
not free.
First, before you ship the offending machine out for repair, remove the
RAM, Hard Disks and particularly the caching SCSI controller. Keep
these parts under secure lockup until the machine has been repaired and
returned. Before you lock up the RAM I suggest you boot from the
diagnostice disk that came with the machine and run the exhaustive
memory test which writes to every address. With a GiG or so of RAM
should be done in a FFFFFLLLLAAAAASSSSHHHH.
The second option is to convert to NT. That should do it right away.
>
> If you scribble all over /dev/kmem it will screw up all of RAM
including
> the operating system. Your machine will promptly go insane, belch
bytes,
> and probably initiate a nuclear attack. It's the OS equivalent of
throwing
> a wrench into the machinery. Don't do it.
>
> What you should be worrying about is the contents of the hard disk,
not the
> RAM. Unlike RAM, the hard disk contents are not volatile. 30 seconds
> after booting your machine, the evil empire will have the entire
contents
> cloned onto backup media and into the hands of the dark side. The
> rebellion will flounder and emperors storm troopers will defeat the
rebels
> of the conglomeration. Obviously, this is highly undesireable.
>
> Removing the hard disk before offering your computer to the high
priests on
> the altar of repair is a bit like getting your car repaired without
the
> engine. The chances of success are rather limited. However, if
you're
> really paranoid, just find some other hard disk, load it up with your
> favorite OS, and may the force be with you.
>
> --
> Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
> (831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
> http://www.cruzio.com/~jeffl WB6SSY
> je...@comix.santa-cruz.ca.us je...@cruzio.com
>
--
Jim Richardson
I like NT because it constantly reminds me of my daughter.
"Honest Daddy, I wasn't doing anything and it just broke."
Sent via Deja.com http://www.deja.com/
Before you buy.
Dave Dickerson
says...
>
>On 3 Jan 2000 04:24:26 GMT, nos...@primenet.com (Dave Dickerson) wrote:
>
>>Reboot. I agree. But the regs want some kind of proactive process done that
>>"touches" each memory address. Sort of like Norton's wipe for magnetic media.
>>
>>Your last suggestion, with the redirection to /dev/kmem, will that write to
all
>>memory address?
>
>Oh swell. You're serious. I hate that.
>
>the operating system. Your machine will promptly go insane, belch bytes,
>and probably initiate a nuclear attack. It's the OS equivalent of throwing
>a wrench into the machinery. Don't do it.
>
>What you should be worrying about is the contents of the hard disk, not the
>RAM. Unlike RAM, the hard disk contents are not volatile. 30 seconds
>after booting your machine, the evil empire will have the entire contents
>cloned onto backup media and into the hands of the dark side. The
>rebellion will flounder and emperors storm troopers will defeat the rebels
>of the conglomeration. Obviously, this is highly undesireable.
>
>Removing the hard disk before offering your computer to the high priests on
>the altar of repair is a bit like getting your car repaired without the
>engine. The chances of success are rather limited. However, if you're
>really paranoid, just find some other hard disk, load it up with your
>favorite OS, and may the force be with you.
>
>
>--
>Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
>(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
>http://www.cruzio.com/~jeffl WB6SSY
>je...@comix.santa-cruz.ca.us je...@cruzio.com
Point taken on the hard drive - the secure machine has removable drive so
that's no problem.
I also am not fond of having to take this subject seriously. It's policy
written by physical security folk who don't know the technical realities.
Sometiimes you just have to go through the motions, check off the box, and move
on - it's easier than trying to explain that things just don't work that way.
If there is no way to actually *do* what they want, a placebo will do just
fine.
Dave Dickerson
Dave Dickerson
Thank you for your insights. I'll use this information in my comments back to
the security folks. Maybe a little light will come on in their heads.
--
Ben Rosenthal
Dave Dickerson wrote:
There are PC test and diagnostic programs that do a destructive test of the
memory. I do not remember the name of the one I used to use, but I am sure they
still exist.
Ben
Dave Mundt
jo...@kuwait.net (John Temples) wrote:
*snip*
>DRAM can maintain its contents for seconds, even minutes, after
>losing power. If absolute certainty is required, removing the power
>isn't good enough.
*snip*
Perhaps there is a bit of a misconception here. Keeping
information in semiconductor memory is like carrying water in a sieve.
It may be possible, but the damn thing leaks constantly. The only way
it works at all is because there is circuitry that continually reminds
each bit what state it is supposed to be in (the so-called refresh
cycles). If these refresh cycles stop for any length of
time...specifically a few milliseconds...the memory randomizes its
contents.
Now...there ARE certain types of memory that DO maintain their
contents with power removed...Core memory (which for those youngsters
out there are thousands of tiny doughnuts of metal, strung on a
complex grid of wires), EE/EPROMS (which are too slow and unwieldy to
use for the sorts of things that RAM is used for).
As far as *I* know everything else turns to random mush moments
after you remove the power to it. Even if some useful information WAS
maintained for a few minutes in the RAM, that would still not present
a security risk in the case of maintenance being done on the machine,
because at the very LEAST it would take half an hour for the machine
to get out of the secured area and to the shop.
>I see no way that this can be accomplished under something like OSR5.
>I think you'd need a dedicated program you could boot from a floppy
>to do the job. Or swap the RAM modules before handing the machine
>over to the insecure party.
Of course, by pulling the DRAM out, would remove any remaining
voltages that MIGHT possibly maintain information.
Overall, I agree with the other posters that have said these arre
regs created by the clueless.
Perhaps you should point out to them that they run a far greater
security risk of folks using sophisticated electronic equipment to
monitor and record the electronic emissions from the computers,
thereby allowing them to see EVERYTHING that is displayed on the
screen.
The only place that non-volatile information is stored is on the
disk drives, and, there it is still pretty shaky. If the machine
requires maintenance, then, pulling the hard drive out will be a minor
inconvenience for the techs. I usually have at least one spare drive
about which I have put in machines myself, to replace their hard drive
and help me determine if the problem was the drive itself. If the
hard drive is dead, then, physically destroying it by melting it down
will eliminate any chance of the data on it being retrieved.
Regards
Dave Mundt
Remove the mapson. from the email address to get to me...
I hate Cullers who gather from newsgroups
Visit my home page at http://www.esper.com/xvart/index.html
Bill Vermillion
<nos...@primenet.com> wrote:
>What would one do, by way of running a command or command script,
>to assure that content of RAM has been erased/overwritten?
>I have a SCO OpenServer 5.0.5 Desktop machine that processes
>sensitive data that will soon be under security requirements that
>should RAM need replacing, the old RAM must be erased/overwritten
>(by some number of passes of 0's & 1's, I assume) before removal.
Well dynamic RAM - but it's nature being basically a capacitive
storage element will be erased when you remove it.
However if someone insists that the memory be cleared run something
like the AMIDIAG (or equivalent) on a memory test that writes all
zeroes, then all 1's, the checkboards, then walking bits, etc.
Figure about up to an hour for a 256MB RAM based machine.
--
Bill Vermillion bv @ wjv.com
Dave Dickerson
>
>*snip*
> Perhaps there is a bit of a misconception here. Keeping
>information in semiconductor memory is like carrying water in a sieve.
>It may be possible, but the damn thing leaks constantly. The only way
>it works at all is because there is circuitry that continually reminds
>each bit what state it is supposed to be in (the so-called refresh
>cycles). If these refresh cycles stop for any length of
>time...specifically a few milliseconds...the memory randomizes its
>contents.
> Now...there ARE certain types of memory that DO maintain their
>contents with power removed...Core memory (which for those youngsters
>out there are thousands of tiny doughnuts of metal, strung on a
>complex grid of wires), EE/EPROMS (which are too slow and unwieldy to
>use for the sorts of things that RAM is used for).
> As far as *I* know everything else turns to random mush moments
>after you remove the power to it. Even if some useful information WAS
>maintained for a few minutes in the RAM, that would still not present
>a security risk in the case of maintenance being done on the machine,
>because at the very LEAST it would take half an hour for the machine
>to get out of the secured area and to the shop.
>
> Of course, by pulling the DRAM out, would remove any remaining
>voltages that MIGHT possibly maintain information.
> Overall, I agree with the other posters that have said these arre
>regs created by the clueless.
> Perhaps you should point out to them that they run a far greater
>security risk of folks using sophisticated electronic equipment to
>monitor and record the electronic emissions from the computers,
>thereby allowing them to see EVERYTHING that is displayed on the
>screen.
> The only place that non-volatile information is stored is on the
>disk drives, and, there it is still pretty shaky. If the machine
>requires maintenance, then, pulling the hard drive out will be a minor
>inconvenience for the techs. I usually have at least one spare drive
>about which I have put in machines myself, to replace their hard drive
>and help me determine if the problem was the drive itself. If the
>hard drive is dead, then, physically destroying it by melting it down
>will eliminate any chance of the data on it being retrieved.
> Regards
> Dave Mundt
>
Good points all. Thanks.
If it should add some spice to the thread, now that I'm back at work: I notice
the regulation states the memory only needs to be purged if the sensitive data
is suspected of residing in RAM for the past 72 hours.
RAM burnin??
DD in AZ
Bill Vermillion
Dave Dickerson <nos...@primenet.com> wrote:
>If it should add some spice to the thread, now that I'm back at
>work: I notice the regulation states the memory only needs to be
>purged if the sensitive data is suspected of residing in RAM for
>the past 72 hours.
>RAM burnin??
In a speculation mode here. Since RAM stores it's memory in what
are effectivly small capacitors, and the charge drains off quickly
when powered off, could there be extremly small residual charges
left for xx hours after power-off.
I know the procedure is to physically destroy hard drives because
minute magnetic charges can remain. When you have the resources of
a government power you can afford some pretty exotic equipment and
do some amazing things.
Dave Dickerson
definitely nothing exotic. Not even a super tar. The point is not understood
until some General or politician gets burned, THEN the money flows.
DD in AZ
larry
Bill Vermillion <bi...@wjv.com.REMOVEME> wrote in message
news:Fnrt1...@wjv.com.REMOVEME...
> In article <84oi1c$65j$1...@nnrp02.primenet.com>, Dave Dickerson
> <nos...@primenet.com> wrote:
>
> >What would one do, by way of running a command or command script,
> >to assure that content of RAM has been erased/overwritten?
>
> >I have a SCO OpenServer 5.0.5 Desktop machine that processes
> >sensitive data that will soon be under security requirements that
> >should RAM need replacing, the old RAM must be erased/overwritten
> >(by some number of passes of 0's & 1's, I assume) before removal.
>
> Well dynamic RAM - but it's nature being basically a capacitive
> storage element will be erased when you remove it.
>
> However if someone insists that the memory be cleared run something
> like the AMIDIAG (or equivalent) on a memory test that writes all
> zeroes, then all 1's, the checkboards, then walking bits, etc.
>
> Figure about up to an hour for a 256MB RAM based machine.
>
> Bill Vermillion bv @ wjv.com
Dual boot with Windows and load somthing like "War And Peace" into MS-Word.
This should
occupy all available memory, and the OS will also be overwritten. Let it
cook for an hour, while you play
solitaire.
--
larry
--------------------------------------------------------------
There is an infinite amount of knowledge in the universe.
I can only learn an finite amount of it.
Any finite number compared to inifinity is as zero compared to infinity.
Therefore, I know nothing.
-------------------------------------------------------------
Geoff Munn
Dave Dickerson <nos...@primenet.com> wrote in message
news:84q4pl$fdh$3...@nnrp02.primenet.com...
> In article <DuXb4.3345$W41....@dfiatx1-snr1.gtei.net>, John Temples
says...
> >
> >In article <8c107sgn55mfv8e2e...@4ax.com>,
> >Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
> >>Dynamic RAM does not permanently store bits. Turn off the power, and
all
> >>the stored bits are cleared.
> >
> >losing power. If absolute certainty is required, removing the power
> >isn't good enough.
> >
> >> sync; sync; sync
> >> /usr/bin/yes "Garbage and more garbage" > /dev/kmem
> >>which is guaranteed to overscribble all of memory.
> >
> >Including the kernel and the "yes" executable and its shared
> >libraries which are all resident in memory. You'd have no guarantee
> >that all of memory was wiped before the wiping program itself was
> >wiped.
> >
> >I think you'd need a dedicated program you could boot from a floppy
> >to do the job. Or swap the RAM modules before handing the machine
> >over to the insecure party.
> >John W. Temples, III
>
>
> Thank you for your insights. I'll use this information in my comments back
to
> the security folks. Maybe a little light will come on in their heads.
>
> --
> -------------------------------
> DD in AZ
> ------------------------------
> To get a working email address
> replace nospam with dickers
> ------------------------------
>
will definitely require the 16lb hammer.
Geoff Munn
- bill -
Now...there ARE certain types of memory that DO maintain their
> contents with power removed...Core memory (which for those youngsters
> out there are thousands of tiny doughnuts of metal, strung on a
> complex grid of wires), EE/EPROMS (which are too slow and unwieldy to
> use for the sorts of things that RAM is used for).
> As far as *I* know everything else turns to random mush moments
don't forget cmos which has a little bitty battery to keep it alive.
Some kinds of proprietary ram-disks and caching scsi controllers do
also.
--
-bill-
Technical Service Systems - bi...@TechServSys.com