Re: Draft CERT bulletin (was Re: LYNX-DEV security.html)

[Jonathan Sergent]

David wrote:
 ] This draft has too much exploit detail, in the first case, to fit
 ] the style for CERT bulletins.  CERT work on the security by obscurity
 ] principle, so bulletins limit themselves to the scope of the problem
 ] (which version, operating systems/operating system characteristics) and
 ] the final results of an attack (e.g. overwrite files owned by anyone who
 ] uses Lynx).  They then describe specific avoidance techniques without
 ] explaining how they work.

*snip*

I understand fully what you're saying... however, this isn't going to be 
a CERT advisory, it's going to be a CERT vendor bulletin.  I think it 
would be better to let CERT CC decide what level of information they 
think it would be prudent for us to publish!

I'll look at the comments that have been brought up and see if I can
do new drafts that address the concerns.

I did purposefully omit the URLs of the lynx-dev messages detailing
the DOWNLOAD exploit.  It's probably trivial to do a web search to
find the information, however...

 ] I haven't checked the URLs given, but those most at risk are likely to be
 ] those using pre-compiled binaries, so it is more or less essential that 
 ] pointers to pre-compiled versions for likely operating systems are given
 ] (I would suggest that Linux, SCO (all versions), and Solaris need to be
 ] given, as the very minimum - in fact, any system where either the development
 ] system is unbundled, or it is used by people without a Unix background,
 ] needs to be included).

I've contributed binaries to Subir's repository before, once we decide on
what to do release-wise I think we can get a nice new collection of them.
I can, as usual, do Linux, HP-UX, and Solaris.

I'm sure there are still several SCO people on the list who might be
willing to compile and distribute binaries for their platforms.

 ] The other common practice on CERT bulletinns is to include the MD5
 ] checksum (and possibly PGP) of the relevant fixed versions, so that people
 ] can be sure they have a legitimate copy.

I figured I'd wait until we had final text for the thing before doing
anything like that.  Jim, since you've appointed yourself go-between
or whatever you called it, you should probably sign the bulletin.

As far as signing the code itself, I've contributed MD5 and PGP for
all of the binaries I've contributed to Subir's repository.  It
wouldn't be a bad idea to do the same for Lynx source releases.

Someone could create a release key (keeping it at SLCC seems appropriate 
since that's the official release point now), and all of the developers 
could sign it.

...

Re: Scott's message

It's been some time since I've actually downloaded and built with FOTEMODS.
Do we believe that it's stable enough to release?  I would recommend a
version number such as 2.7.9, and I would number the final merged code
(with everything in FOTEMODS plus autoconf, curses color, non-buggy styles,
etc.) 2.8.

If 2.7.1+FOTEMODS (must resist temptation to abbreviate that as 2.7.1-FM!)
isn't stable enough to release, I think that administrators facing this
problem would be grateful if the security fixes were backported to 2.7.1.
Replacing LYDownload.c fixes one problem, it shouldn't be too much more
difficult to get the $USER support and the additional /tmp checking code
backported as well.


--jss.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;