|
|
| Linux Proves Security of Open Source: First Back-Door Attempt Thwarted |
 |
|
Sunday, November 09 2003 @ 05:34 AM EST
|
The Open Source method has been validated once more as a potentially catastrophic back door in the kernel was detected and removed before it could even reach the code stage. Linus says the incident "wasn't really bad at all."
In an article in The Register, it was disclosed that an unknown party attempted to bypass the normal submission procedures for Linux code in an attempt to get the back door incorporated into the kernel. Alert Linux coders quickly spotted the alterations and picked up on their hidden intent, despite the clever way they were coded to obfuscate their purpose, a classic example of why the open source method is so effective and so quick to spot and fix security problems: "'Whoever did this knew what they were doing,' says Larry McVoy, founder of San Francisco-based BitMover, which hosts the Linux kernel development site that was compromised. 'They had to find some flags that could be passed to the system without causing an error, and yet are not normally passed together... There isn't any way that somebody could casually come in, not know about Unix, not know the Linux kernel code, and make this change. Not a chance.'
"However sophisticated, the hack fell apart Wednesday, when a routine file integrity check told McVoy that someone had manually changed a copy of a kernel source code file that's normally only modified by an automated process, specifically one that pulls the code from BitMover's BitKeeper software collaboration tool and repackages it for the open source CVS system still favored by some developers.
"Even then, McVoy didn't initially recognize the change as a backdoor, and he announced to the Linux kernel developers list as a procedural annoyance. Other programmers soon figured out the trick, and by Thursday an investigation into how the development site was compromised was underway, headed by Linux chief Linus Torvalds, according to McVoy." More details here. How long have bugs and exploitable insecurities remained in Windows in the past before Microsoft even admitted there was a problem, much less fixed it? Proprietary companies may try to offer this incident as proof Linux and/or the open source method is not secure, but it is, in fact, proof of the opposite: an extremely subtle and sophisticated attempt to hijack the kernel was thwarted almost instantaneously, before any harm could be done, long before it reached the user. Newsforge adds this: "The code, if it had become part of the final kernel release, would have allowed a remote user to take control of machines running that Linux kernel version. Unauthorized code snippets, often called Easter Eggs, are common in closed-source programs but are relatively rare in the open source world. It's easy for developers to hide either humorous or malicious code in programs whose inner workings are hidden, but as this Linux kernel incident shows, the open source development process carries a degree of built-in immunity to this kind of problem."
An investigation into the source of the offending code is underway, headed by Linus Torvalds, according to this report by McVoy: "Linus & Dave have tracked down the machine from which the break in happened, it was a University, that University has been contacted, is cooperating, and has discovered that a number of their machines have rootkits installed. So they are working backwards to try and track down where those breakins came from." This is, according to McVoy, the first known malicious attempt to install a back door in Linux, probably because it is well-known that Linus reads every line of code personally before it is accepted into the kernel.
The unflappable Linus emailed Newsforge his take on the situation: "It wasn't really bad at all - except of course in the sense that it's always a nasty surprise that somebody would try something like that. But on a scale from 'insignificant' to 'very very serious' I'd call the hack attempt 'interesting'.
"Inserting a back-door into a project CVS tree could be very serious in theory, and in that sense everything was done 'right' - the code was made to look innocuous, and the CVS history looked fairly sane. Successfully doing something like that into the core CVS tree would quite potentially be very hard to detect, and two lines of code out of five million is obviously not a sore thumb that sticks out.
"But the thing is, unlike a lot of other projects, Linux kernel development isn't actually done using a central CVS tree _at_all_. That CVS-tree was just an automatically generated read-only export for people who want to use CVS, and the back-door was never in any 'real' tree in that sense. The real trees aren't public, and never have been."
|
|
|
|
| Authored by: Anonymous on Sunday, November 09 2003 @ 06:54 AM EST |
Which Dave is it that is looking into things? Someone at BitMover or a kernel
developer?[ Reply to This | # ]
|
- Which Dave? - Authored by: Anonymous on Sunday, November 09 2003 @ 07:16 AM EST
| |
| Authored by: maxhrk on Sunday, November 09 2003 @ 07:04 AM EST |
they fixed the problem under 24 hours is impressive I must say. I think that was
first hack attempted since 6 years accord to Larry McVoy on Kerneltraps.org If i
remembered correctly, though.
---
SCO: Linux... I am your.. father.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 07:16 AM EST |
It seems like the development procedure of the Linux is very trustworthy and
highly secure, since they're not developing using a CVS tree and Linus
personally authorize every patch that goes into his development tree.
Question is: what about other OSS projects? Most OSS development project are
done via CVS tree. What happened if someone managed to hack into the CVS of any
other project and put some harmful code in there? Unlike this case, it wouldn't
be detected automatically.
It might be detected during some manual view. But would it be detected? How many
eyes practically review each line of code in most OSS projects? While the code
is opn for millions to review it, I don't believe more than 2-3 people are
usually reviewing a certain piece of code in a certain project.
Don't get me wrong - I am a very strong believer in open-source and free (as in
speech) software, but I want to make sure we do not make unrealistic claims.
I don't say that open-source is necessarily less secure that closed source. I
guess the Linux kernel is more secure than most closed-source programs I can
think of, due to its development process. However, I'm not sure if it is true
for any other open-source project.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 07:19 AM EST |
This is really proof of the value of BitKeeper (combined with CVS) along with
the validity of open source security mechanisms (i.e. peer review).
When you combine strong change detection methods with a bunch of eyes looking at
the code, it becomes a lot harder to create intentional backdoors.
The bigger question, though, is who did it?
In the last few months, we've seen the announcement of Linux adoption by not
just large companies but rising economies throughout the world. China, Japan,
Germany and other countries have announced official support for Linux (and
reciprocally announced concern for the security flaws and somewhat well known
back doors in MS operating systems). While Linux certaintly isn't perfect, who
would have the incentive to pull this kind of clever trick?
(1) Microsoft
Na, they simply can't code that well.
(2) U.S. Government
Na, they simply code too well to try this. At least initially, I'd like to
think that it wasn't them. On the other hand, while getting basic user access
to an unprotected machine is easy, this exploit fills the other side of the
equation--once you have basic access, it would give you an easy way to root.
Ah, I sure miss the 0.* kernels where you could simply pipe one tty to another,
even from a user tty to a root tty. Talk about exploits. I guess that's what
SCO means by a "toy" operating system.
(3) Third countries/syndicates
More likely. Someone, possibly a large syndicate or corporate organization,
paid a third party to attempt this opening. It was someone who was very well
versed with Unix programming and someone familiar, but not too familiar, with
the linux code process.
I have no specific information on who did this. But if anything, rather than
gloating over how good Linux development security is, I think this requires a
vetting of the entire codebase and of recent logs.
If you remember, someone invaded the FSF GNU archive a few months ago as well.
Someone should see whether the other side of this exploit was inserted in one of
the less common GNU utilities when that happened.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 07:57 AM EST |
I suspect there will be FUD along the lines of "see, anyone can just add
backdoors into open source code."
As someone with experience in commercial software development, I am sure the
amount of code review the average commercial code gets is nowhere near as great
as open source software.
It would trivial for most commercial developers to add malicous code to their
companies products without anyone knowing.
Just remember that next time you go to vote in a county using closed-source
voting computers...
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 10:27 AM EST |
Any backdoor change in code would have to pass the MD5 checksum to be
undetected, and that's an impossibility in itself. The failure of the code to
pass the MD5 checksum test focused attention on its nature and it was soon
identified for what it was. IBM to its credit caught on years ago that just
because most OSS developers work for free does not mean they are stupid or
ignorant.[ Reply to This | # ]
|
| |
| Authored by: eamacnaghten on Sunday, November 09 2003 @ 11:09 AM EST |
Now is not the time to get complacent about such things.
The hack failed. There was security in place, but we were lucky.
There will be other attempts, and more sophisticated attempts. A rogue
developer may break into the "inner circle" and place something like
this in the kernel.
Linux security (of this nature) is good, but it needs to be continuously
refined. Authentication and approval of developers need to be continuously
examined, procedures on what to do if something goes wrong need to be reviewed
and decided upon, and all the rest.
The OSDL, and others, have their work cut out in this area. It is a nuisance
because it is costky and does not produce anything, but it is a neccessity, more
and more hacks of increasing sophisticallity will be attempted.
Now is not the time for complacency.
[ Reply to This | # ]
|
| |
| Authored by: beast on Sunday, November 09 2003 @ 11:49 AM EST |
Here is a link to a classic paper in which Ken Thompson discusses a backdoor
that he and Dennis Ritchie put into the early versions of UNIX. The important
point here is that the backdoor was hidden in a binary version of the
original C compiler.
Reflections on Trusting
Trust
As I understand it, they did this because in the early days
of UNIX they personally were being called out to answer support problems. It
was easier if they could have a built in super-user account on every UNIX
system. :^)
This means that it not enough to just have access to the
source for something like the Linux kernel or an application. One must also
have access to the source for the entire toolchain (compiler, assembler, etc.)
used to build the program in question. But that is still not enough, because
what if someone has broken into your system and compromised your compiler
binary? You need to compare the output of the build process with one produced
by a "known good" version of the toolchain.
This is the problem that I
have with Microsoft's "Shared Source" Initiative. As far as I am aware,
Microsoft is only showing the source code to Windows but not to their toolchain
and build system. For any company or government that looks at Microsoft's
source code, what guarantee do they have that the code they see corresponds to
the binaries that they get from MS?
[ Reply to This | # ]
|
- Trust... - Authored by: maxhrk on Sunday, November 09 2003 @ 12:13 PM EST
- Trust... - Authored by: MathFox on Sunday, November 09 2003 @ 02:53 PM EST
- Trust... - Authored by: Anonymous on Sunday, November 09 2003 @ 03:03 PM EST
- Trust... - Authored by: mflaster on Sunday, November 09 2003 @ 08:54 PM EST
- Trust... - Authored by: Anonymous on Sunday, November 09 2003 @ 03:01 PM EST
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 12:16 PM EST |
> This is, according to McVoy, the first known malicious attempt to
install a back door in Linux, probably because it is well-known that Linus reads
every line of code personally before it is accepted into the
kernel.
A while back, I recall a lot of talk about how Linus "is
becoming a bottleneck," how we "need to find a way to get things into the kernel
faster," and how we "need to automate the kernel submission
procedure."
It struck me as a FUD campaign at the time, because it
seemed to appear everywhere at once.
I believed then, and still do,
that the purpose of that campaign was to get the kernel developers to adopt a
system that would have new code entering the kernel too fast for Linus to
review, and thus make it easier for someone (i.e. Microsoft) to pollute the
kernel with Trojan code.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 12:30 PM EST |
The consequences of successfully inserting an unauthorised patch (regardless of
whether it compromised security) in Linux would be utterly devastating.
Commercial users would lose all trust in the system.
As with personal relationships, trust is hard to achieve and easily broken, and
once lost extremely difficult to regain. An unauthorised patch would cause
every CIO to institute immediate steps to verify that there were not other
unauthorised patches, there would be immediate calls for tighter controls, and
it would be a bonanza for any company feeling threatened by Open Source
software.
Furthermore, it's not just the Operating System that needs strong patch
protection. Clearly, drivers and any other code that run at kernel level needs
to be carefully controlled. Less obviously, there are other ways to subvert a
system. A compiler patch (authorised or otherwise) can completely destroy
system security and might be extremely difficult to detect.
Frankly, I think that writing this article was not a good idea. Pointing out
that someone made an unauthorised patch that made it so far into the system is
not a good idea. Not only does it say "look we found this attempt"
but it also says "look how many checks and balances were easily
circumvented". Far from being a triumph for us that we should trumpet to
the world, it was a narrow escape that shows us in a poor light. I believe that
this incident will cause many managers to become more wary of open source
software.
I work for a nationally known hardware manufacturer. If a back door was added
to our code it would have huge potential for damage, not only to the systems
compromised by the back door but also to the company's reputation. To prevent
this type of exploit we have a number of checks and balances. These include all
software changes being reviewed by a second engineer who has to certify the
changes, verification of the identity of the person checking in any changes and
the reviewer, complete and secure audit trails of code changes, and a number of
routine automated validations. To successfully insert an unauthorised patch a
malicious person would have to have an understanding of our internal systems,
internal network access, the passwords for two authorised engineers (the coder
and the code reviewer), and the ability to disable some automated checks.
Open source software is on the verge of breaking into the big-time. Any hint of
source security issues will impact the adoption of open source by commercial and
government users. Now that there has been one attempt there will be others, and
it is vital that this issue is addressed quickly and fully by the community.
Source code control for Linux and GNU needs to be brought up to commercial
standards quickly, and potential switchers to open source assured that this type
of event cannot happen again.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 02:18 PM EST |
How long have bugs and exploitable insecurities remained in Windows in the
past before Microsoft even admitted there was a problem, much less fixed it?
Proprietary companies may try to offer this incident as proof Linux and/or the
open source method is not secure, but it is, in fact, proof of the opposite: an
extremely subtle and sophisticated attempt to hijack the kernel was thwarted
almost instantaneously, before any harm could be done, long before it reached
the user.
There's a world of difference between bugs and attempts
to insert malicious code. I'm not aware of any proprietary operating systems
that have shipped with deliberately malicious code. I seriously doubt that any
company such as IBM, MS or Apple has even had an attempt to insert malicious
code - most large companies expend a great deal of effort to control their
source and have audit trails to verify where every line of code came from. A
programmer pulling that sort of trick wouldn't just be fired, he'd be looking at
civil and criminal prosecution. After he got out of prison he'd be paying
damages for the rest of his life.
Is anyone aware of any other attempts
in to insert bad code into an OS? I suspect that this is indeed a problem
unique to open source.[ Reply to This | # ]
|
- Bugs vs. Malicious Code - Authored by: Anonymous on Sunday, November 09 2003 @ 02:56 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: beast on Sunday, November 09 2003 @ 02:56 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: Anonymous on Sunday, November 09 2003 @ 02:56 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: MathFox on Sunday, November 09 2003 @ 03:10 PM EST
- Yes. - Authored by: Anonymous on Sunday, November 09 2003 @ 03:13 PM EST
- Yes. - Authored by: Anonymous on Sunday, November 09 2003 @ 03:26 PM EST
- Yes. - Authored by: Anonymous on Sunday, November 09 2003 @ 03:57 PM EST
- Interesting - Authored by: Anonymous on Sunday, November 09 2003 @ 04:15 PM EST
- Yes. - Authored by: maxhrk on Sunday, November 09 2003 @ 04:41 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: Anonymous on Sunday, November 09 2003 @ 03:22 PM EST
- Government-"requested" Backdoors - Authored by: Anonymous on Sunday, November 09 2003 @ 03:32 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: smtnet1 on Sunday, November 09 2003 @ 04:08 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: Anonymous on Sunday, November 09 2003 @ 05:31 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: Anonymous on Sunday, November 09 2003 @ 08:19 PM EST
- Has any OS apart from Linux been attacked like this? - Authored by: Anonymous on Monday, November 10 2003 @ 05:44 AM EST
| |
| Authored by: Grim Reaper on Sunday, November 09 2003 @ 02:56 PM EST |
<EOM>
---
For the love of money is a root of all kinds of evil (1 Timothy 6:10); R.I.P. -
SCO Group, 2005/08/29[ Reply to This | # ]
|
| |
| Authored by: brenda banks on Sunday, November 09 2003 @ 03:34 PM EST |
what i desire is the fact that my system is more stable with linux.i feel more
secure because i control what i put on here.
most people that run desktops dont even realize there is another choice.but when
they do it will be a flood exodus to change because most are sick of the worms
and viri
br3n
---
br3n[ Reply to This | # ]
|
| |
| Authored by: Alizarin on Sunday, November 09 2003 @ 03:46 PM EST |
A deviously clever change if I do say so myself... the kerneltrap.org article
has a posting of the 2 lines that were changed. I didn't even notice it at
first, but as I looked at it more I realized it was an = instead of an ==... and
believe me, I've made that mistake a few times in my code, it's hard to find
if you're not looking for it.
Kudos to the people who found it.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 03:46 PM EST |
I am worried about other stuff like this slipping in.
This wouldn't be a remote root exploit without something else going wrong, but
who knows how many other attempts have been made? Really subtle exploits happen
even when people are doing their best, it's not impossible for someone to
insert one intentionally. Many eyes don't always catch everything.[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 09:39 PM EST |
If we are to better understand this situation, it may help to research who the
players and/or commentators are.
Make of this what you will, if anything. I do not know if any of the following
might be connected.
1. EsNet, vSpring, Sorenson Media, Canopy, CMGI @ Ventures Fund and Wasatch Fund
fund MyFamily.com
http://www.asiawired.com/startups/startup/report0107_20010805.pdf
2. EsNet and Caldera leases
1997:
http://techdeals.startup.findlaw.com/agreements/sco/esnet.lease.1997.10.09.html
2000:
http://techdeals.startup.findlaw.com/agreements/sco/esnet.lease.2000.04.05.html
3. SCO board member, R.Duff Thompson
http://www.sco.com/company/execs/
Mr. Thompson has served as Managing General Partner of EsNet, Ltd., an
investment group that is active in both technology and real estate ventures from
1996 to the present
Also in:
http://www.sec.gov/Archives/edgar/data/1102542/000109581100002653/sc13d.txt
4. New SCO board member, Dan Campbell
http://www.hostingtech.com/news/2003/11/6/St_Nitf_SCO_Appoints_Dan_Campbell_as_M
_p1105061.1rw.html
Campbell has served as a Managing General Partner of EsNet, Ltd., an investment
group that is active in both technology and real estate ventures, from July 1994
to the present.
5. Dan Campbell and R. Duff Thompson both served at WordPerfect, and seemed to
be working closely together. They both were involved in the merger discussions
with Novell (Noorda era).
Dan Campbell was Chief Financial Officer (CFO) of WordPerfect
R. Duff Thompson was General Counsel of WordPerfect
They did seem to be working together (see many references in the book which can
be found in the index). See "The Microsoft File : The Secret Case against
Bill Gates" by Wendy Goldman Rohm
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Sunday, November 09 2003 @ 10:00 PM EST |
If we are to better understand this situation, it may help to research who the
players and/or commentators are.
Make of this what you will, if anything. I do not know if any of the following
might be connected.
1. "Stock Watch: Soundview Acquisition Strengthens Wit Capital"
http://www.ecommercetimes.com/perl/story/1631.html
2. Soundview Technology Group and Wit Capital involved in Caldera IPO
See last two paragraphs of
http://news.zdnet.co.uk/software/0,39020381,2077431,00.htm
3. SoundView and Caldera IPO
Note: I have not checked subsequent filings for what they might contain - if
anything.
http://www.sec.gov/Archives/edgar/data/1102542/0001035704-00-000192-index.html
For example: see Page 73 tag of filing (page 70 of prospectus)
For example: see Page 75 tag of filing (page 72 of prospectus)
Also
http://www.witsoundview.com/banking/transactions_public.jsp?beginIndex=61
"...SoundView participated as a lead manager or co-manager."
(Caldera is on this page)
4. Wit Soundview mentioned in planned Lineo IPO
http://news.com.com/2100-1001-240842.html
5. SoundView, one of several defendants, in Caldera IPO litigation
http://www.iposecuritieslitigation.com/Caldera.pdf
http://linuxtoday.com/infrastructure/2001071200820NWCD
6. Does Soundview have anything to say about the SCO story?
Some things I noticed
(i) SCO filed their suit on Thursday March 6. SoundView seems to have published
a report on this by Monday March 10th (see 12 March newsobserver.com article)
(ii) SoundView seems to have published a research note on SCO on Tuesday August
5 (see August 6 thestreet.com article)
(iii) The number of, and content of, Soundview's comments
(iv) SCO seem to have had discussions with SoundView about suing a customer
(September 5 linuxworld.com article)
(v) Soundview seem to have made several comments on SCO's effect on Red Hat
prior to July 28. I have not found any subsequent Soundview comments on SCO's
effect on Red Hat (which simply means that I didn't find any, there might be
some that I have not seen). Note: There are SoundView has commented on other Red
Hat issues after July 28, (for example:
http://newsobserver.com/front/digest/story/2880938p-2656001c.html ), just not
any ones that I've seen regarding the SCO effect on Red Hat.
* 12 March 2003 (a Wednesday)
http://newsobserver.com/business/story/2312268p-2170641c.html
"It's kind of irrelevant who wins the lawsuit," said Victor Raisys,
analyst with Soundview Technology Group in San Francisco. "You can't take
back the fact that someone has tried to claim intellectual property on Linux.
The genie is out of the bottle."
On Monday, Raisys released a report aimed at investors that said the lawsuit
shouldn't be dismissed as another licensing squabble. "Linux customers
and vendors will be forced to consider their legal liability due to intellectual
property issues," he wrote.
* 17 June 2003
http://aol.thestreet.com/tech/billsnyder/10094379.html
Although the AIX and Linux questions are somewhat different, the action is
"another shot across Linux's bow," said analyst Victor Raisys of
the SoundView Technology Group.
Raisys said he doesn't expect the case to be settled in the near future, which
means customer uncertainty about Linux could continue -- a negative for Red Hat.
* 17 July
http://www.wallstreetandtech.com/story/WST20030717S0004 <--- n.b. some Blake
Stowell and Trink Guarino quotes in here, might not be in database, etc.
Victor Raisys, an analyst at investment firm Soundview Technology Group, a
market maker for Linux firm Red Hat, says, "The lawsuit represents more
than just a licensing squabble between two companies or the efforts of a small
UNIX/Linux company to dig into the deep pockets of IBM."
He says Linux customers will "be forced to consider their legal liability
due to intellectual property issues around Linux and open-source
software." Raisys says Linux clients are "struck with a lot of
uncertainty" and he expects "some firms will put them (Linux
deployments) on hold until they get better clarity."
While some commentators argue the simplest solution would be for IBM to buy SCO,
Raisys says that's easier said than done. Given that the lawsuit claims more
than $1 billion in damages, it's unlikely the shareholders would cough up their
shares at the current market cap. "You won't see this thing settled for
quite a while."
* 28 July 2003 (approx)
http://www.bizjournals.com/triangle/stories/2003/07/28/focus1.html
[Red Hat] "could see some long-term fallout".
* 28 July 2003 (approx)
http://www.bizjournals.com/triangle/stories/2003/07/28/focus1.html?page=2
"If enough customers get concerned about the liability involved in running
Linux, it will negatively impact Red Hat in the long run."
* 6 August 2003
http://technologyreports.net/enterpriseinnovator/?articleID=1950
SoundView recently hosted the second in its Linux Conference Call series, with
Dr. Irving Wladawsky-Berger, IBM’s VP - Systems Group & GM,
e-Business on Demand. He was joined by Jim Stallings, GM – Linux, and
for a brief introductory appearance, Cory List, head of IBM's investor
relations department. At the start of the call, List explained that because of
ongoing litigation, the SCO Group lawsuit would not be discussed directly -- but
it was discussed ‘indirectly’ in so much depth and detail
that few mysteries remained on that topic by the end of the call.
AND
When asked by SoundView is IBM was considering releasing its own Linux
distribution, Stallings said an emphatic “no!” He added,
“That’s just not the way the industry works
* 6 August - a Wednesday
http://www.thestreet.com/pf/tech/ronnaabramson/10106296.html
But in the long term, SCO's actions have the potential to dampen Linux's
growth until the issue is resolved, Soundview analyst Victor Raisys said in a
research note Tuesday. Trial in the IBM case is set for April 11, 2005.
* 5 September 2003
http://www.linuxworld.com/story/35362.htm
Soundview Technology has contributed to the debate by saying that "Based
on our discussions with the company, we believe that one of the next steps SCO
may take will be to sue a Linux customer resulting in additional anxiety and
confusion in the Linux market."
* 22 September 2003
http://www.newsfactor.com/perl/story/22340.html
"Linux adoption continues to grow in spite of the SCO lawsuit,"
analyst Victor Raisys of Soundview Technology told NewsFactor, "but I
think the suit is having an effect on the Linux market."
AND
In the Linux community, developers and engineers have been claiming for months
that SCO's suit is baseless, even though the firm has placed its evidence under
seal until the case can be heard in court. That may not be until 2005.
"I'm not sure that the Linux community can really make an assessment on
whether the damage to Linux will be great or not great," says Raisys,
"until we really know the hand that SCO is holding."
6. Victor Raisys of Soundview covers Red Hat's stock
(and incidentally so does Brian Skiba of Deutsche Bank Securities)
http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=RHAT&script=500
We do know from various press reports that Brian Skiba has seen the SCO
"proof".
I do not know whether, or whether not, Victor Raisys has or has not.
7. Victor Raisys of SoundView rates SCO stock
has an "Avoid" rating on Red Hat. To be complete, he seems to have
given them negative ratings since 2002.
According to this page on 16 September 2003, he puts a $4/share target on Red
Hat
http://www.stockselector.com/analystinfo.asp?analyst=7630
and
http://www.stockselector.com/analysts.asp?symbol=RHAT
At time of writing this, current Red Hat share price is $13.53/share. On 16
September 2003, it looks like it was just over $8
http://finance.yahoo.com/q/bc?s=RHAT&t=3m&l=off&z=m&q=l&c=
It is interesting to compare Victor Raisys's target price for RHAT to other
analysts' (at time of writing, average recommendation is Moderate Buy, average
target price $13) according to:
http://www.stockselector.com/analysts.asp?symbol=RHAT
As I'm not a stock analyst, I have no idea whether Raisys's or other
analysts' predictions are more likely to be correct.
[ Reply to This | # ]
|
| |
| Authored by: Anonymous on Monday, November 10 2003 @ 12:37 AM EST |
If we are to better understand this situation, it may help to research who the
players and/or commentators are.
Make of this what you will, if anything. I do not know if any of the following
might be connected.
1. Morgan Keegan & Co., Inc. - selling shares
Morgan Keegan selling approximately 200,000 shares
http://www.sec.gov/Archives/edgar/data/1102542/000104746903012127/a2107735zs-3a.
htm
Article about this: http://lwn.net/Articles/35523/
Perhaps the most interesting filing so far is this S/3A form, first filed in
February and since updated several times. It appears that two external
stockholders, John R. Wall and Morgan Keegan & Co., have decided to dump an
even million shares that they hold. SCO has gone through the whole registration
process - at its expense - to make this happen, but the proceeds go directly to
the two sellers.
Mr. Wall got his (800,000) shares at the end of 2002 (along with $100,000 in
cash) for a $1 million note payable by Vista.com, a company he founded. Those
shares, at current prices, are worth nearly $7 millon. Not a bad deal.
Morgan Keegan was retained by the company "to act as an exclusive
financial advisor to assist the Company in its analysis, consideration and if
appropriate, execution of various financial and strategic alternatives available
to it including, but not limited to, securing additional equity and/or debt
capital and potential strategic transactions including mergers, acquisitions and
joint ventures" (2002 annual report). The cynical among us might conclude
that a "strategic alternative" has indeed been chosen. There is,
however, no evidence that either of these two large shareholders have anything
to do with the lawsuit - they are simply happy beneficiaries.
2. Morgan Keegan & Co. to benefits if SCO gets financing or is acquired
http://www.zdnet.com.au/newstech/enterprise/story/0,2000048640,20273310,00.htm
The second is Morgan Keegan & Co., an investment banking firm that in August
received a warrant for 1.6 percent of SCO, or 200,000 shares. SCO retained the
firm to explore and possibly execute plans including finding financing or
selling SCO to another company, according to SCO's filing for the quarter ended
31 January.
Under the agreement, Morgan Keegan would get between 1 percent and 6 percent of
money raised. If SCO is acquired or acquires others, Morgan Keegan would receive
the greater of US$250,000 or 2 percent of the transaction price, according to
the filing.
3. Morgan Keegan & Co. calling up potential Linux licensees in Hollywood
http://story.news.yahoo.com/news?tmpl=story2&u=/fo/20031106/bs_fo/5797da4499
d3f424b70cac76d4ffa384&e=3&ncid=1817
By contrast, the assault on Hollywood has started on a softer note. SCO claims
it has had brief conversations with executives at Fox, Universal and Sony
Pictures. Patrick Scholes, an investment banker at Morgan Keegan & Co. who
advises SCO, says that on Oct. 9 he spoke by phone with Mitch Singer, a senior
vice president at Sony Pictures, broaching the fact that Hollywood companies use
a lot of Linux. Scholes says Singer understood the implication. "He said,
Okay, I can read between the lines,'" Scholes recalls.
4. Morgan Keegan & Co. get $2m as a result of SCO's BayStar deal
http://www.sec.gov/Archives/edgar/data/1102542/000110465903023055/a03-4160_18k.h
tm
"The SCO Group, Inc. (“SCO”) has received a
$50,000,000 private investment from two investors, including BayStar Capital II,
LP (“BayStar”)."
"SCO will pay its investment banker, Morgan Keegan & Company, Inc., a
fee equal to 4 percent of the gross proceeds."
Note 1: 4 percent of $50m = $2m
[ Reply to This | # ]
|
| |
| Authored by: bbaston on Monday, November 10 2003 @ 12:52 AM EST |
I asked an old hand at programming of open source software "How should the
world's most secure and reliable software be made?" This was after a six
pack or two, but I feel like I was in the presence of royaly.
"Ben, its simple!" he said
1. Start with what it must do, knowing that security procedures involve a proper
team effort on even simple jobs.
Gather you friends, the ones you trust and who dream in C.
2. Truely high-quality review of the software is needed in all directions. These
frinds should argue freely.
3. Several programmers should discuss and argue over competing designs for each
activity of the program.
3. Decisions affect stability, security and user interface, so must be evaluated
for each change.
4. Trusted peer review means people discussing and reading and arguing the code
together.
5. In the case of processes for national secuity, for protecting citizens,
intelligent user participents should agree only when all are comfortable that
the overall requirements are met.
6. All of these steps together require open source methods to succeed. Review
and discusison must happen between peers.
7.Expert users should bombard the code mercilessly and report back to the
coders.
8. When a product seems to be at hand, all involved take a really critical look
at each others work.
9. By the time it's ready for beta, the source should be md5summed and secured
at several sites, so lockdown is applied from that time on for any changes
10. You must get trusted beta feedback, and the bug communication and fix cycle
must be short, minutes or hours, and if necessary triaged.
11. When the trusted feedback subsides, go back to step 1.
-------------
Lock us in an old mountain house, an old lake house, or a brewery, feed us pizza
and beer, and watch perfection in software be achieved. I'll be the dishwasher.[ Reply to This | # ]
|
| |
| Authored by: pyrite on Tuesday, November 11 2003 @ 01:11 PM EST |
From Infoworld - it's funny:
http://www.infoworld.com/article/03/11/11/HNmsassault_1.html
"Microsoft Corp. is preparing a major PR assault over Windows' perceived
security failings in which it will criticize Linux for taking too long to fix
bugs, we have learned."
I thought it was a joke, but from the looks of things, it isn't.
[ Reply to This | # ]
|
|
|
|
|
