| Summary: | net-misc/capi4hylafax missing input sanitising (CVE-2006-3126) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | comm-fax+disabled, s, sbriesen |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.debian.org/security/2006/dsa-1165 | ||
| Whiteboard: | B1 [glsa] jaervosz | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2006-09-02 04:41:28 UTC
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 |