Re: squeeze update of macopix?
Ben Hutchings 於 2015年12月31日 06:37 寫道:
> On Wed, 2015-12-30 at 20:19 +0800, Ying-Chun Liu (PaulLiu) wrote:
> [...]
>> I've made a patch. As attachment.
>
> I don't think it's a complete fix, as it doesn't check that there's
> enough space for the terminating null (or shift sequence, where
> needed).
>
>> Should I just push it to unstable? Or I need to do some further steps
>> before that?
>
> You should probably coordinate with maintainers of other affected
> packages, e.g. claws-mail. There is an upstream fix for claws-mail,
> although it's not quite right (see my comment on security-tracker).
>
>> I didn't see any bug numbers against macopix package for CVE-2015-8614.
>> What's the best next step?
>
> So far as I know it's not necessary to create a bug report, though
> there's no harm in doing so.
>
> Ben.
>
Hi Ben,
I synced the code from the claws-mail upstream which fixes the bug.
Please see the attachment.
Yours,
Paul
--
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu)
Description: Fix CVE-2015-8614
I tried to move the code from latest claws-mail upstream which fixes
the bug already.
Author: Ying-Chun Liu (PaulLiu)
Last-Update: 2016-02-14
Index: macopix-1.7.4/src/codeconv.c
===
--- macopix-1.7.4.orig/src/codeconv.c
+++ macopix-1.7.4/src/codeconv.c
@@ -128,10 +128,14 @@ typedef enum
void conv_jistoeuc(gchar *outbuf, gint outlen, const gchar *inbuf)
{
const guchar *in = inbuf;
- guchar *out = outbuf;
+ gchar *out = outbuf;
JISState state = JIS_ASCII;
- while (*in != '\0') {
+ /*
+ * Loop outputs up to 3 bytes in each pass (aux kanji) and we
+ * need 1 byte to terminate the output
+ */
+ while (*in != '\0' && (out - outbuf) < outlen - 4) {
if (*in == ESC) {
in++;
if (*in == '$') {
@@ -192,6 +196,7 @@ void conv_jistoeuc(gchar *outbuf, gint o
}
*out = '\0';
+ return ;
}
#define JIS_HWDAKUTEN 0x5e
@@ -263,10 +268,15 @@ static gint conv_jis_hantozen(guchar *ou
void conv_euctojis(gchar *outbuf, gint outlen, const gchar *inbuf)
{
const guchar *in = inbuf;
- guchar *out = outbuf;
+ gchar *out = outbuf;
JISState state = JIS_ASCII;
- while (*in != '\0') {
+ /*
+ * Loop outputs up to 6 bytes in each pass (aux shift + aux
+ * kanji) and we need up to 4 bytes to terminate the output
+ * (ASCII shift + null)
+ */
+ while (*in != '\0' && (out - outbuf) < outlen - 10) {
if (isascii(*in)) {
K_OUT();
*out++ = *in++;
@@ -286,26 +296,32 @@ void conv_euctojis(gchar *outbuf, gint o
}
} else if (iseuchwkana1(*in)) {
if (iseuchwkana2(*(in + 1))) {
- guchar jis_ch[2];
- gint len;
-
- if (iseuchwkana1(*(in + 2)) &&
- iseuchwkana2(*(in + 3)))
- len = conv_jis_hantozen
- (jis_ch,
- *(in + 1), *(in + 3));
- else
- len = conv_jis_hantozen
- (jis_ch,
- *(in + 1), '\0');
- if (len == 0)
- in += 2;
- else {
- K_IN();
- in += len * 2;
- *out++ = jis_ch[0];
- *out++ = jis_ch[1];
- }
+if (0) {
+ HW_IN();
+ in++;
+ *out++ = *in++ & 0x7f;
+} else {
+ guchar jis_ch[2];
+ gint len;
+
+ if (iseuchwkana1(*(in + 2)) &&
+ iseuchwkana2(*(in + 3)))
+ len = conv_jis_hantozen
+ (jis_ch,
+ *(in + 1), *(in + 3));
+ else
+ len = conv_jis_hantozen
+ (jis_ch,
+ *(in + 1), '\0');
+ if (len == 0)
+ in += 2;
+ else {
+ K_IN();
+ in += len * 2;
+ *out++ = jis_ch[0];
+ *out++ = jis_ch[1];
+ }
+}
} else {
K_OUT();
in++;
@@ -340,14 +356,19 @@ void conv_euctojis(gchar *outbuf, gint o
K_OUT();
*out = '\0';
+ return ;
}
void conv_sjistoeuc(gchar *outbuf, gint outlen, const gchar *inbuf)
{
const guchar *in = inbuf;
- guchar *out = outbuf;
+ gchar *out = outbuf;
- while (*in != '\0') {
+ /*
+ * Loop outputs up to 2 bytes in each pass and we need 1 byte
+ * to terminate the output
+ */
+ while (*in != '\0' && (out - outbuf) < outlen - 3) {
if (isascii(*in)) {
*out++ = *in++;
} else if (issjiskanji1(*in)) {
@@ -386,6 +407,7 @@ void conv_sjistoeuc(gchar *outbuf, gint
}
*out = '\0';
+ return ;
}
void conv_anytoeuc(gchar *outbuf, gint outlen, const gchar *inbuf)
signature.asc
Description: OpenPGP digital signature
CVE-2015-7519
Hi Linus,
as others might be interested in the answer as well, I also send it to
debian-lts@.
On irc you wrote:
15:05 < Nirkus> have some old redmine running on squeeze-lts (yeah..) and
since the update yesterday the following redmine code bails out with
"private method `split' called for nil:NilClass" at the following line:
15:06 < Nirkus> @env['QUERY_STRING'].present? ? @env['QUERY_STRING'] :
(@env['REQUEST_URI'].split('?', 2)[1] || '')
15:11 < Nirkus> ah, the code is actually from: libactionpack-ruby1.8:
/usr/lib/ruby/1.8/action_controller/request.rb
15:51 < Nirkus> downgrading to libapache2-mod-passenger=2.2.11debian-2
fixes the above issue...
In CVE-2015-7519[1] it was detected, that it is possible to obtain
unauthorized access if you send http variables with "_" instead of "-".
More information can be found here[2]. As a solution it was proposed to
simply filter out all variables containing an "_". This was already done
in mod_cgi of apache[3] and now I applied a similar patch to
libapache2-mod-passenger as well.
Unfortunately there seems to be software that relies on underscores in
variable names. So if you need such variables you might want to use the
workaround for apache, described in[2].
Thorsten
[1] https://security-tracker.debian.org/tracker/CVE-2015-7519
[2] https://blog.phusion.nl/2015/12/07/cve-2015-7519/
[3]
http://mail-archives.apache.org/mod_mbox/httpd-dev/201010.mbox/<201010121630.19406@apache.org>
Re: [PATCH] Given a package allow to check in which releases security support has ended
Hi Guido, On Mittwoch, 17. Februar 2016, Guido Günther wrote: > When triaging LTS issues I always have to look up what we still support > and what not. Attached script simplifies this a bit: > > $ bin/support-ended.py --lists /path/to/debian-security-support/ iceape > Package unsupported in wheezy > Package unsupported in squeeze very nice! > I didn't find a place in Debian where we canonically map release names > to release numbers (i.e. squeeze -> 6.x, jessie -> 7.x). I'm sure there > is such a thing so I'm happy about any pointers. apt-cache show distro-info :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Given a package allow to check in which releases security support has ended
On Thu, Feb 18, 2016 at 09:35:14AM -0500, Antoine Beaupré wrote: > On 2016-02-18 02:26:28, Guido Günther wrote: > > Hi, > > On Wed, Feb 17, 2016 at 01:39:41PM -0500, Antoine Beaupré wrote: > >> On 2016-02-17 12:13:35, Guido Günther wrote: > >> > When triaging LTS issues I always have to look up what we still support > >> > and what not. Attached script simplifies this a bit: > >> > > >> > $ bin/support-ended.py --lists /path/to/debian-security-support/ > >> > iceape > >> > Package unsupported in wheezy > >> > Package unsupported in squeeze > >> > > >> > Does this make sense? It would be great if we could later add this to > >> > the scripts mangling data/CVE/list to add the entries > >> > automatically. What would be the right place for that? > >> > > >> > I didn't find a place in Debian where we canonically map release names > >> > to release numbers (i.e. squeeze -> 6.x, jessie -> 7.x). I'm sure there > >> > is such a thing so I'm happy about any pointers. > >> > >> Good idea, couldn't this be integrated in find-work? > > > > Either that one or in lts-cve-triage so we can mark them upfront when > > triaging bugs. > > > > Carnil pointed out that he does not just mark packages as > > but rather checks beforehand if the vulnerable code is present at all > > and marks them as if not even if the package is > > unsupported. This gives a lower bound on the affected versions. I wonder > > if we should adopt the same practice to ease the work of the security > > team a bit? At least in cases where it's rather simple to check. So for > > packages unsupported in the LTS release > > > > : not supported but vulnerability likely present > > : vulnerable code not present > > The problem here is that LTS is so old that it is sometimes very > difficult to figure out if a vulnerability is present. Upstream and the > CVE material most likely do *not* even *know* if older versions are > vulnerable... > > So it's great to check, but sometimes it takes a long time, and I am not > sure it is worth spending that time on a unsupported package. So i think > it should rather be: > >: not supported but vulnerability possibly present >: vulnerable code not present > > ie. on unsupported packages, we *can* mark an issue non-affected if we > have reasons to believe it is not, but if it's too complicated to check, > end-of-life is also fine, and does *not* mean there is necessarily a > vulnerability. *possibly* is a better word than *likely* in this case, I agree. I'd suggest that we then document if we tried to pin down the vulnerability in the commit message. Cheers, -- Guido
Re: [PATCH] Given a package allow to check in which releases security support has ended
On 2016-02-18 02:26:28, Guido Günther wrote: > Hi, > On Wed, Feb 17, 2016 at 01:39:41PM -0500, Antoine Beaupré wrote: >> On 2016-02-17 12:13:35, Guido Günther wrote: >> > When triaging LTS issues I always have to look up what we still support >> > and what not. Attached script simplifies this a bit: >> > >> > $ bin/support-ended.py --lists /path/to/debian-security-support/ iceape >> > Package unsupported in wheezy >> > Package unsupported in squeeze >> > >> > Does this make sense? It would be great if we could later add this to >> > the scripts mangling data/CVE/list to add the entries >> > automatically. What would be the right place for that? >> > >> > I didn't find a place in Debian where we canonically map release names >> > to release numbers (i.e. squeeze -> 6.x, jessie -> 7.x). I'm sure there >> > is such a thing so I'm happy about any pointers. >> >> Good idea, couldn't this be integrated in find-work? > > Either that one or in lts-cve-triage so we can mark them upfront when > triaging bugs. > > Carnil pointed out that he does not just mark packages as > but rather checks beforehand if the vulnerable code is present at all > and marks them as if not even if the package is > unsupported. This gives a lower bound on the affected versions. I wonder > if we should adopt the same practice to ease the work of the security > team a bit? At least in cases where it's rather simple to check. So for > packages unsupported in the LTS release > > : not supported but vulnerability likely present > : vulnerable code not present The problem here is that LTS is so old that it is sometimes very difficult to figure out if a vulnerability is present. Upstream and the CVE material most likely do *not* even *know* if older versions are vulnerable... So it's great to check, but sometimes it takes a long time, and I am not sure it is worth spending that time on a unsupported package. So i think it should rather be: : not supported but vulnerability possibly present : vulnerable code not present ie. on unsupported packages, we *can* mark an issue non-affected if we have reasons to believe it is not, but if it's too complicated to check, end-of-life is also fine, and does *not* mean there is necessarily a vulnerability. a. -- You Are What You Is - Frank Zappa
