Koozali.org: home of the SME Server
Legacy Forums => Experienced User Forum => Topic started by: wellsi on September 24, 2005, 12:09:01 AM
-
The maintenance team would like to announce that the following packages are available from the updates repositories for SME 6.0 & 6.0.1. These updates can also be applied to 6.5RC1.
To update your server see http://no.longer.valid/phpwiki/index.php/How%20to%20update%20SME%20Server
To help this process see http://no.longer.valid/phpwiki/index.php/Maintenance%20Process
libtool-libs-1.4.2-13.legacy.i386.rpm
FL Note: http://www.fedoralegacy.org/updates/RH7.3/2004-05-18-FLSA_2004_1268__Updated_libtool_resolves_security_vulnerability.html
FL Bug : https://bugzilla.fedora.us/show_bug.cgi?id=1268
The chmod utility has a race (that access to the temporary directory could
be gained after it is created but before it is chmoded)
apache-1.3.27-8.legacy.i386.rpm
FL Note: http://www.fedoralegacy.org/updates/RH7.3/2005-08-10-FLSA_2005_157701__Updated_Apache_httpd_packages_fix_security_issues.html
FL Bug : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157701
Watchfire reported a flaw that occured when using the Apache server as
an HTTP proxy. A remote attacker could send an HTTP request with both a
"Transfer-Encoding: chunked" header and a "Content-Length" header. This
caused Apache to incorrectly handle and forward the body of the request
in a way that the receiving server processes it as a separate HTTP
request. This could allow the bypass of Web application firewall
protection or lead to cross-site scripting (XSS) attacks. The Common
Vulnerabilities and Exposures project (cve.mitre.org) assigned the name
CAN-2005-2088 to this issue.
A buffer overflow was discovered in htdigest that may allow an attacker
to execute arbitrary code. Since htdigest is usually only accessible
locally, the impact of this issue is low. The Common Vulnerabilities and
Exposures project (cve.mitre.org) assigned the name CAN-2005-1344 to
this issue.
Marc Stern reported an off-by-one overflow in the mod_ssl CRL
verification callback. In order to exploit this issue the Apache server
would need to be configured to use a malicious certificate revocation
list (CRL). The Common Vulnerabilities and Exposures project
(cve.mitre.org) assigned the name CAN-2005-1268 to this issue.
Users of Apache httpd should update to these errata packages that
contain backported patches to correct these issues.
gzip-1.3.3-1.2.legacy.i386.rpm
FL Note: http://www.fedoralegacy.org/updates/RH7.3/2005-08-10-FLSA_2005_157696__Updated_gzip_package_fixes_security_issues.html
FL Bug : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157696
A bug was found in the way zgrep processes file names. If a user can be
tricked into running zgrep on a file with a carefully crafted file name,
arbitrary commands could be executed as the user running zgrep. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2005-0758 to this issue.
A bug was found in the way gunzip modifies permissions of files being
decompressed. A local attacker with write permissions in the directory
in which a victim is decompressing a file could remove the file being
written and replace it with a hard link to a different file owned by the
victim, gunzip then gives the linked file the permissions of the
uncompressed file. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-0988 to this issue.
A directory traversal bug was found in the way gunzip processes the -N
flag. If a victim decompresses a file with the -N flag, gunzip fails to
sanitize the path which could result in a file owned by the victim being
overwritten. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2005-1228 to this issue.
Users of gzip should upgrade to this updated package, which contains
backported patches to correct these issues.
mc-4.5.55-12.legacy.i386.rpm
FL Note: http://www.fedoralegacy.org/updates/RH7.3/2005-08-10-FLSA_2005_152889__Updated_mc_packages_fix_security_issues.html
FL Bug : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152889
Several buffer overflows, several temporary file creation
vulnerabilities, and one format string vulnerability have been
discovered in Midnight Commander. These vulnerabilities were discovered
mostly by Andrew V. Samoilov and Pavel Roskin. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
names CAN-2004-0226, CAN-2004-0231, and CAN-2004-0232 to these issues.
Shell escape bugs have been discovered in several of the mc vfs backend
scripts. An attacker who is able to influence a victim to open a
specially-crafted URI using mc could execute arbitrary commands as the
victim. The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CAN-2004-0494 to this issue.
Several format string bugs were found in Midnight Commander. If a user
is tricked by an attacker into opening a specially crafted path with mc,
it may be possible to execute arbitrary code as the user running
Midnight Commander. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2004-1004 to this issue.
Several buffer overflow bugs were found in Midnight Commander. If a user
is tricked by an attacker into opening a specially crafted file or path
with mc, it may be possible to execute arbitrary code as the user
running Midnight Commander. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2004-1005 to this
issue.
Several denial of service bugs were found in Midnight Commander. These
bugs could cause Midnight Commander to hang or crash if a victim opens a
carefully crafted file. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the names CAN-2004-1009, CAN-2004-1090,
CAN-2004-1091, CAN-2004-1092, CAN-2004-1093 and CAN-2004-1174 to these
issues.
A filename quoting bug was found in Midnight Commander's FISH protocol
handler. If a victim connects via embedded SSH support to a host
containing a carefully crafted filename, arbitrary code may be executed
as the user running Midnight Commander. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2004-1175 to
this issue.
A buffer underflow bug was found in Midnight Commander. If a malicious
local user is able to modify the extfs.ini file, it could be possible to
execute arbitrary code as a user running Midnight Commander. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
name CAN-2004-1176 to this issue.
A buffer overflow bug was found in the way Midnight Commander handles
directory completion. If a victim uses completion on a maliciously
crafted directory path, it is possible for arbitrary code to be executed
as the user running Midnight Commander. The Common Vulnerabilities and
Exposures project (cve.mitre.org) has assigned the name CAN-2005-0763 to
this issue.
Users of mc are advised to upgrade to these packages, which contain
backported security patches to correct these issues.
-
Hi i was just looking at the yum updates.
It seems that a lot of these updates are fairly standard redhat packages. Is it really necessary to do # /sbin/e-smith/signal-event post-upgrade
# /sbin/e-smith/signal-event reboot
Or is this only with certian packages.
Kust that i do not like to reboot more often than i have to.
Adam
-
It is always safest to do the full sequence.
In the case of these four updates it is essential that apache is restarted for the update to take effect. This need not be a full re-boot.
-
Hey Yall,
to anyone else running an SME6.5rc1 box,
here is some input.
My production box web server, web mail, basic file server,
lightly modified with add-on contribs.
I went into the /etc/yum.conf file and made changes to
the directories(there isn't a functioning .../6.5RC1/updates/ dir on the mirror, YET!)
The changes to the yum.conf, make the yum updater look in the .../6.0.1/updates/ dir on the mirror.
The update appears to have went fine, server is up and running! Your mileage may vary!
Hope this helps.
Joe
-
Hey Yall,
to anyone else running an SME6.5rc1 box,
here is some input.
My production box web server, web mail, basic file server,
lightly modified with add-on contribs.
I went into the /etc/yum.conf file and made changes to
the directories(there isn't a functioning .../6.5RC1/updates/ dir on the mirror, YET!)
The changes to the yum.conf, make the yum updater look in the .../6.0.1/updates/ dir on the mirror.
The update appears to have went fine, server is up and running! Your mileage may vary!
Hope this helps.
Joe
Yes, you are correct, that is the same thing I currently do. You should have downloaded 18 updates. The maintenance team is currently working on getting the 6.5 support in place. Hopefully we will have an announcement out on that shortly.
JB
-
I have gone into the updates folder and there isn't any files in there. So where is YUM suppose to get the updates for 6.0-1
-
I have gone into the updates folder and there isn't any files in there. So where is YUM suppose to get the updates for 6.0-1
Yeah, the directory structure is changing. Possibly a symlink needs to be put in place during the transition. The updates are now currently in the updates-common directory.
http://mirror.contribs.org/smeserver/releases/6.0.1/updates-common/i386/
You will have to manually change your yum.conf until the new one is released. I'll send a note to the maintenance team so that all are aware of this issue.
JB
-
Thanks for the reply :)
-
Yeah, the directory structure is changing. Possibly a symlink needs to be put in place during the transition. The updates are now currently in the updates-common directory.
http://mirror.contribs.org/smeserver/releases/6.0.1/updates-common/i386/
You will have to manually change your yum.conf until the new one is released. I'll send a note to the maintenance team so that all are aware of this issue.
JB
Hi,
Just to be shure
I’ll change my /etc/yum.conf to the following:
[updates]
name=SME Server $releasever updates
baseurl=http://mirror.contribs.org/smeserver/releases/$releasever/updates-common/i386/
gpgcheck=0
If yes, I have another failure, as there are NO updates
-
Yeah, the directory structure is changing. Possibly a symlink needs to be put in place during the transition. The updates are now currently in the updates-common directory.
http://mirror.contribs.org/smeserver/releases/6.0.1/updates-common/i386/
You will have to manually change your yum.conf until the new one is released. I'll send a note to the maintenance team so that all are aware of this issue.
JB
Hi,
Just to be shure
I’ll change my /etc/yum.conf to the following:
[updates]
name=SME Server $releasever updates
baseurl=http://mirror.contribs.org/smeserver/releases/$releasever/updates-common/i386/
gpgcheck=0
If yes, I have another failure, as there are NO updates
You didn't say what version you are using. You should be able to verify the files as well.
http://mirror.contribs.org/smeserver/releases/6.0/updates-common/i386/
http://mirror.contribs.org/smeserver/releases/6.0.1/updates-common/i386/
http://mirror.contribs.org/smeserver/releases/6.5RC1/updates-common/i386/
Caveat, I haven't yet myself tried to update a server with the new locations. Someone else did, however. I'll get around to this in the next couple of days.
Or, you can go to one of those directories and manually download and install the latest yum RPM which has the changes to the new directory structure.
Worse case, you will have to manually download the updates until someone can look into whether this is an issue or now. Not, the best solution, but it will work in the short-term.
JB
-
Firstly, a hearty thanks to those putting up the updates.
A question:
I have seen that there are more updates available in the 'updates-testing-common' repositories.
How do we know how important it is to include these updates? Are the 'updates-common' the security patches, and the 'updates-testing-common' patches for system bug-squashing?
-
Firstly, a hearty thanks to those putting up the updates.
A question:
I have seen that there are more updates available in the 'updates-testing-common' repositories.
How do we know how important it is to include these updates? Are the 'updates-common' the security patches, and the 'updates-testing-common' patches for system bug-squashing?
Yes, and yes.
I'll try to explain this a little more. The updates-common area are for updates that can apply to 6.0, 6.0.1, and 6.5RC1. The same applies for the updates-testing-common. updates-common should be ready for primetime and updates-testing-common for testing before being moved to updates-common. I'll try to draft a e-mail to send to the list that explains this as well.
JB
-
About MC update, why not use
http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/binaries/RedHat/7.x/mc-4.6.0-2.i386.rpm
?
This is sugest http://www.ibiblio.org/mc/ page
I have installed and run perfect. And has a lot of syntax highlighting.
I don't know if 4.6.0 has security bugs, but run ok.
Normando
-
I must be doing something wrong. I get the following output from YUM..
Welcome to SME Server 6.0.1-01
[root@teddy root]# cd yum
[root@teddy yum]# yum update
Gathering package information from servers
Getting headers from: SME Server 6.x base updates
Getting headers from: SME Server 6.0.1 os
Getting headers from: SME Server 6.0.1 updates
Finding updated packages
Downloading needed headers
Resolving dependencies
....identical dependency loop exceeded
package libtool needs pam = 1.4.2-7 (not provided)
package libtool needs pam = 1.4.2-7 (not provided)
package pam-devel needs pam = 0.75-46.7.3 (not provided)
package pam-devel needs pam = 0.75-46.7.3 (not provided)
[root@teddy yum]# ls
rpm-python-4.0.4-7x.18.i386.rpm yum-1.0.3-7sme03.noarch.rpm
[root@teddy yum]#
Any ideas...?
-
Ok.. sorted.
Got the rpm's from fedora.
I must have installed some developer stuff along the way...
-
The maintenance team would like to announce that the following packages are available from the updates repositories for SME 6.0 & 6.0.1. These updates can also be applied to 6.5RC1.
To update your server see http://no.longer.valid/phpwiki/index.php/How%20to%20update%20SME%20Server
To help this process see http://no.longer.valid/phpwiki/index.php/Maintenance%20Process
Users of mc are advised to upgrade to these packages, which contain
backported security patches to correct these issues.
Hi,
As I’m moving to newer hardware I’ve been testing this update and they works fantastic – thanks to the maintenance team.
How about the updates made by Knuddi: http://forums.contribs.org/index.php?topic=23074.msg91669#msg91669
Should they be applied to the YUM or are they not needed anymore?
About YUM the European users might be happier with the following mirrors set in the /etc/yum.conf:
[common-updates]
name=SME Server 6.x base updates
baseurl=http://mirror.contribs.org/smeserver/releases/$releasever/updates-common/i386/
gpgcheck=0
[updates]
name=SME Server $releasever updates
baseurl=http://mirror.contribs.org/smeserver/releases/$releasever/updates/i386/
gpgcheck=0
This mirror runs at least 400 kb/s from my location in Copenhagen :-D
-
.. and for Australia:
[os]
name=SME Server $releasever os
baseurl=http://mirror.pacific.net.au/pub/ibiblio/distributions/smeserver/releases/$releasever/os/e-smith/RPMS/
gpgcheck=0
[common-updates]
name=SME Server 6.x base updates
baseurl=http://mirror.pacific.net.au/pub/ibiblio/distributions/smeserver/releases/$releasever/updates-common/i386/
gpgcheck=0
[updates]
name=SME Server $releasever updates
baseurl=http://mirror.pacific.net.au/pub/ibiblio/distributions/smeserver/releases/$releasever/updates/i386/
gpgcheck=0
-
Ok.. sorted.
Got the rpm's from fedora.
I must have installed some developer stuff along the way...
Could you send me a link to which fedora and rpm's you used?
Thanks,
Alex
-
They were for Redhat 7.3 from Fedora legacy.
It was only these two that I needed from memory..
https://www.magicwilly.info/yum/rpm/ (https://www.magicwilly.info/yum/rpm/)
Ok.. sorted.
Got the rpm's from fedora.
I must have installed some developer stuff along the way...
Could you send me a link to which fedora and rpm's you used?
Thanks,
Alex