Bugzilla Bug 145982

Lionel Elie Mamane discovered a security vulnerability in capi4hylafax, tools
for faxing over a CAPI 2.0 device, that allows remote attackers to execute
arbitrary commands on the fax receiving system.

comm-fax please advise.

comm-fax please advise.

Stefan, pls patch/bump the ebuild

I look at it asap.

hmm, capi4hylafax-01.02.03* is outdated, I will remove them all.

but I have to version bump the capi4hylafax-01.03.00.3 to
capi4hylafax_01.03.00.99.svn.300-3. I hurry up, but this is more work than I
thought.

ok, capi4hylafax-01.03.00.99.300.3 is in CVS.

beside the fact, that this is one of the ugliest version strings I've ever
seen, this version runs fine for me. ;-)

I've sent/received several faxes and it just worked as expected. arch herds
should test it quickly, then it can become stable asap.

Excellent, thanks Stefan!

Arches, please test and mark stable capi4hylafax-01.03.00.99.300.3

Target keywords: "amd64 ppx x86".

After emerging the update.with.the.long.version.string on my AMD64 box,
c2faxrecv took the phone for all MSNs. I had to update config.faxCAPI as
follows:

  IncomingMSNs:  12345-12346

to restrict c2faxrecv to only watch MSN 12345. 

If this is intended behaviour, you might want to add a note to postinstall
information ...

Kind regards,
Stefan

hmmm, I don't think that this is intended.

BUT: my config looks like this (I have a AVM C2), shortend to the relevant
parts:

{
    # Controller 1 (PSTN, MSN 919108)
    HylafaxDeviceName:          fax919108
    OutgoingController:         1
    OutgoingMSN:                "919108"
    {
        Controller:             1
        AcceptSpeech:           1
        IncomingMSNs:           "919108"
        AcceptGlobalCall:       0
    }
}

{
    # Controller 1 (PSTN, MSN 983271)
    HylafaxDeviceName:          fax983271
    OutgoingController:         1
    OutgoingMSN:                "983271"
    {
        Controller:             1
        AcceptSpeech:           1
        IncomingMSNs:           "983271"
        AcceptGlobalCall:       0
    }
}

{
    # Controller 2 (Asterisk, MSN 983272)
    HylafaxDeviceName:          fax983272
    OutgoingController:         2
    OutgoingMSN:                "983272"
    {
        Controller:             2
        AcceptSpeech:           1
        IncomingMSNs:           "983272"
        AcceptGlobalCall:       0
    }
}

as you can see, I have configured 3 virtual CAPI FAX "modems". Two of them are
connected to the PSTN (controller 1) and listen only to one of my MSNs each
(one for my wife, one for me). Furthermore, I have the 2nd Controller
loop-connected to my HFC-PCI (Asterisk!). All of them are working properly and
as expected, at least on x86. So I guess, there's just a config error in your
config.faxCAPI.

please attach your config or mail it to me. Thanks.

g64 etc # cat config.faxCAPI
SpoolDir:               /var/spool/fax
FaxRcvdCmd:             /var/spool/fax/bin/faxrcvd
PollRcvdCmd:            /var/spool/fax/bin/pollrcvd
FaxReceiveUser:         uucp
FaxReceiveGroup:        dialout
LogFile:                /var/log/capi4hylafax.log
LogTraceLevel:          4
LogFileMode:            0644
{
    HylafaxDeviceName:          faxCAPI
    RecvFileMode:               0644
    FAXNumber:                  +49.xxxx.306897
    LocalIdentifier:            "SchmiedlFax"
    MaxConcurrentRecvs:         2
    OutgoingController:         1
    OutgoingMSN:                "306897"
    SuppressMSN:                0
    NumberPrefix:
    UseISDNFaxService:          1
    RingingDuration:            0
    {
        Controller:             1
        AcceptSpeech:           1
        UseDDI:                 0
        DDIOffset:
        DDILength:              0
        IncomingDDIs:
        IncomingMSNs:           "306897"
        AcceptGlobalCall:       0
    }
}
g64 etc # c2faxrecv
The config file is /var/spool/fax/etc/config.faxCAPI.
CapiFaxRecv: config-file: An invalid range (306897) with a missing end is
specified in IncomingMSNs


If I now call 306898 or 306899, my phone gives half a ring, then the
fax-beeping starts.

Change IncomingMSNs to "306897-306897" does not change this erroneous
behaviour, setting it to "306897-306898" gets rid of the range warning,
306899 is a normal phone line again, but 306898 is still a fax.

As workaround I have now IncomingMSNs: "306896-306897".

My setting was working fine with the previous ebuilds.

Thanks for looking into this.
s.

on my machine:

~ # c2faxrecv
The config file is /var/spool/fax/etc/config.faxCAPI

nothing else. It just works. Either there is a config-file parser error on
amd64 in this release, or there's somthing wrong with your config. But all I
can say is, it works on my machine.

I'll check debian bugzilla...

ok, compiled and tested on amd64 (used your MSNs for testing):

amd64 ~ # c2faxrecv
The config file is /var/spool/fax/etc/config.faxCAPI.

as you can see: it works

hmm, I tested it again and copied your config 1:1 and now I get the same error.
Please re-create your config using the config.faxCAPI.default template. I guess
the parser is somewhat strange. But with a clean config it should work.

ok, the message is triggered with "LogTraceLevel: 4", with LogTraceLevel: 0"
it's hidden but still there. It is not there on my x86-machine though. So I
guess there's a config parser error on amd64.

hmpf, reverted back to capi4hylafax-01.03.00.3 and the error is gone (on
amd64). I run a diff now...

I know that sound (hmpf) so well ...

In src/faxrecv/ has been changed nothing relevant. And in
src/faxrecv/recvdev.cpp where the error is thrown, there has been changed
NOTHING.

but in src/standard/ there are many changes, though src/standard/ConfPars.* is
unchanged. I check it. But there's no bug open at Debian.

If you set 'AcceptSpeech: 0', the error is not easy to see, as "normal" phone
calls are not accepted anyways. I have 'AcceptSpeech: 1' because a client's fax
is too old to know better ...

Thanks alot for your effort,
s.

ok, found the error!

in src/faxrecv/recvdev.cpp we find this sequence:

  FindPos = MSNlauf->FindChar ('-');
  if (FindPos == MAXVAL_tSize) {

it's the 'if' which failes. I checked it. 'FindPos' is correctly -1 and
MAXVAL_tSize is defined as 

  #define MAXVAL_tSize ((tSize) -1)

and

  typedef tULong  tSize;

where tULong is defined as a uint32_t on 32-Bit machines and on 64-Bit machines
it's uint64_t. 'FindPos' is defined as tSize. So it *should* be correct, but
the 'if' above fails.

Following fix works:

  if ((int)FindPos == (int)MAXVAL_tSize) {

but this can't be the solution, since a similar error can be around everywhere
in the code. I try to finde a real solution.

stay tuned.

ok, now I really found the error:

FindPos is (hex): ffffffff
whereas MAXVAL_tSize is: ffffffffffffffff

last one is correct, first one is wrong. Seems that MSNlauf->FindChar ('-')
somehow returns a 32-Bit unsigned value. Now I have the place where I can
*really* fix it. ;-)

Good job nailing another 32-bit-ism down.

Thanks a lot,
s.

HMPF!!!!!

old version:
tSize CDynamicString::FindChar (tStringChar ch, tSize startpos) {
tSize CDynamicString::FindLastChar (tStringChar ch) {

new version:
tUInt CDynamicString::FindChar (tStringChar ch, tUInt startpos) {
tUInt CDynamicString::FindLastChar (tStringChar ch) {

I make a patch. It's easy now. FindChar is used only 2 times and the other
place is already correct.

ok, -r1 in CVS. I send the patch also upstream.

x86 stable ^.^

works as expected on my amd64, too.

Thanks much for the quick fix.

s.

amd64 + ppc herd? please respond... Just check if it compiles fine for you.

(In reply to comment #26)
> amd64 + ppc herd? please respond... Just check if it compiles fine for you.

It compiles, as i lack the hardware i can't do any further testing. That's
enough for stabling it, Stefan?

(In reply to comment #27)
> (In reply to comment #26)
> > amd64 + ppc herd? please respond... Just check if it compiles fine for you.
> 
> It compiles, as i lack the hardware i can't do any further testing. That's
> enough for stabling it, Stefan?
> 

You quoted the answer already...

For my part, amd64 is stable :)

Ready for glsa/glsa voting then ...

If I didn't miss anything important that's a clear and ugly B1. If any doubt
remains, count me as 'yes'.

B1 -> GLSA , indeed. And yes it's a B1

GLSA 200610-05