Junos OS

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



Expand all | Collapse all

NTP 4.2.0 Autokey Stack Buffer Overflow Vulnerability

Jump to Best Answer
  • 1.  NTP 4.2.0 Autokey Stack Buffer Overflow Vulnerability

    Posted 01-23-2017 08:31

    Hi all,


    Scan results showed a vulnerability (cve-2009-1252) in the ntpd 4.2.0 in all juniper equipenemtns we have which is resolved in other versions like 4.2.5,. this vulnerability can cause DoS when the autokey and openssl are enabled.
    after checking the kB section, I found that junos is not concerned with this vulnerability as described in kb21459, because the autokey security model is disable by default.
    All equipments are in the recommended release.


    how can I prove this to the audit organisation? can I get the ntp.conf file inside the junos?

     

    kb : https://kb.juniper.net/InfoCenter/index?page=content&id=KB21459&smlogin=true&actp=search

    cve : http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2009-1252

    juniper products : srx650 , srx 240 , ex2200 , ex3300 and ex4200


    #cve-2009-1252
    #NTP
    #srx240xdos
    #SRX650
    #stackbuffueroverflow


  • 2.  RE: NTP 4.2.0 Autokey Stack Buffer Overflow Vulnerability

     
    Posted 01-25-2017 03:11

    For these types of audit providing a copy of the kb article you link to is typically sufficient as it demonstrates that the vulnerability has been remediated.



  • 3.  RE: NTP 4.2.0 Autokey Stack Buffer Overflow Vulnerability

    Posted 01-26-2017 03:13

    even if it is for PCI DSS ?



  • 4.  RE: NTP 4.2.0 Autokey Stack Buffer Overflow Vulnerability
    Best Answer

     
    Posted 01-28-2017 05:55

    Yes, this scan is basically a false positive.  The KB article describes how the remediation for the vulnerabillity has been applied and thus supports the response to the reported hit.