Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 145982 - net-misc/capi4hylafax missing input sanitising (CVE-2006-3126)
Summary: net-misc/capi4hylafax missing input sanitising (CVE-2006-3126)
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Whiteboard: B1 [glsa] jaervosz
Depends on:
Reported: 2006-09-02 04:41 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2006-10-17 13:22 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-09-02 04:41:28 UTC
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.
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-09-05 05:21:15 UTC
comm-fax please advise.
Comment 2 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-09-26 13:02:14 UTC
comm-fax please advise.
Comment 3 Matthias Geerdsen (RETIRED) gentoo-dev 2006-09-29 04:46:44 UTC
Stefan, pls patch/bump the ebuild
Comment 4 Stefan Briesenick (RETIRED) gentoo-dev 2006-09-29 05:20:27 UTC
I look at it asap.
Comment 5 Stefan Briesenick (RETIRED) gentoo-dev 2006-09-29 14:39:48 UTC
hmm, capi4hylafax-01.02.03* is outdated, I will remove them all.

but I have to version bump the capi4hylafax- to capi4hylafax_01.03.00.99.svn.300-3. I hurry up, but this is more work than I thought.
Comment 6 Stefan Briesenick (RETIRED) gentoo-dev 2006-09-29 17:08:50 UTC
ok, capi4hylafax- 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.
Comment 7 Tavis Ormandy (RETIRED) gentoo-dev 2006-09-29 23:59:50 UTC
Excellent, thanks Stefan!

Arches, please test and mark stable capi4hylafax-

Target keywords: "amd64 ppx x86".
Comment 8 Stefan Schmiedl 2006-10-03 04:13:22 UTC
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,
Comment 9 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 14:15:00 UTC
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.
Comment 10 Stefan Schmiedl 2006-10-03 14:47:41 UTC
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
    UseISDNFaxService:          1
    RingingDuration:            0
        Controller:             1
        AcceptSpeech:           1
        UseDDI:                 0
        DDILength:              0
        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.
Comment 11 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 14:54:51 UTC
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...
Comment 12 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 15:01:07 UTC
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
Comment 13 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 15:14:00 UTC
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.
Comment 14 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 15:21:43 UTC
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.
Comment 15 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 15:25:59 UTC
hmpf, reverted back to capi4hylafax- and the error is gone (on amd64). I run a diff now...
Comment 16 Stefan Schmiedl 2006-10-03 15:34:52 UTC
I know that sound (hmpf) so well ...
Comment 17 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 15:43:03 UTC
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.
Comment 18 Stefan Schmiedl 2006-10-03 15:49:42 UTC
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,
Comment 19 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 16:35:25 UTC
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)


  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.
Comment 20 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 16:52:06 UTC
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. ;-)
Comment 21 Stefan Schmiedl 2006-10-03 17:04:36 UTC
Good job nailing another 32-bit-ism down.

Thanks a lot,
Comment 22 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 17:05:32 UTC

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.
Comment 23 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-03 17:24:39 UTC
ok, -r1 in CVS. I send the patch also upstream.
Comment 24 Joshua Jackson (RETIRED) gentoo-dev 2006-10-03 21:39:02 UTC
x86 stable ^.^
Comment 25 Stefan Schmiedl 2006-10-04 02:30:54 UTC
works as expected on my amd64, too.

Thanks much for the quick fix.

Comment 26 Stefan Briesenick (RETIRED) gentoo-dev 2006-10-08 12:05:17 UTC
amd64 + ppc herd? please respond... Just check if it compiles fine for you.
Comment 27 Tobias Scherbaum (RETIRED) gentoo-dev 2006-10-09 12:09:07 UTC
(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?
Comment 28 Simon Stelling (RETIRED) gentoo-dev 2006-10-10 01:24:50 UTC
(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 :)
Comment 29 Tobias Scherbaum (RETIRED) gentoo-dev 2006-10-10 08:12:20 UTC
Ready for glsa/glsa voting then ...
Comment 30 Wolf Giesen (RETIRED) gentoo-dev 2006-10-10 13:31:06 UTC
If I didn't miss anything important that's a clear and ugly B1. If any doubt remains, count me as 'yes'.
Comment 31 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-10-13 06:45:05 UTC
B1 -> GLSA , indeed. And yes it's a B1
Comment 32 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-10-17 13:22:03 UTC
GLSA 200610-05